[Public] > -----Original Message----- > From: Jan Beulich <[email protected]> > Sent: Thursday, June 26, 2025 11:51 PM > To: Penny, Zheng <[email protected]> > Cc: Huang, Ray <[email protected]>; Andrew Cooper > <[email protected]>; Roger Pau Monné <[email protected]>; > Anthony PERARD <[email protected]>; Orzel, Michal > <[email protected]>; Julien Grall <[email protected]>; Stefano Stabellini > <[email protected]>; Daniel P. Smith <[email protected]>; > Dario > Faggioli <[email protected]>; Juergen Gross <[email protected]>; George > Dunlap <[email protected]>; Nathan Studer <[email protected]>; > Stewart Hildebrand <[email protected]>; Bertrand Marquis > <[email protected]>; Volodymyr Babchuk > <[email protected]>; Alistair Francis <[email protected]>; > Bob Eshleman <[email protected]>; Connor Davis > <[email protected]>; Oleksii Kurochko <[email protected]>; xen- > [email protected]; [email protected] > Subject: Re: [PATCH v5 00/18] xen: introduce CONFIG_SYSCTL > > On 16.06.2025 08:41, Penny Zheng wrote: > > It can be beneficial for some dom0less systems to further reduce Xen > > footprint via disabling some hypercalls handling code, which may not > > to be used & required in such systems. Each hypercall has a separate > > option to keep configuration flexible. > > > > Options to disable hypercalls: > > - sysctl > > - domctl > > - hvm > > - physdev > > - platform > > > > This patch serie is only focusing on introducing CONFIG_SYSCTL. > > Different options will be covered in different patch serie. > > > > Features, like LIVEPATCH, Overlay DTB, which fully rely on sysctl op, > > will be wrapped with CONFIG_SYSCTL, to reduce Xen footprint as much as > possible. > > > > It is derived from Stefano Stabellini's commit "xen: introduce kconfig > > options to disable hypercalls"( > > https://lore.kernel.org/xen-devel/20241219092917.3006174-1-Sergiy_Kibr > > [email protected]) > > > > Penny Zheng (16): > > xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE" > > xen/xsm: wrap around xsm_sysctl with CONFIG_SYSCTL > > xen/sysctl: wrap around XEN_SYSCTL_readconsole > > xen/sysctl: make CONFIG_TRACEBUFFER depend on CONFIG_SYSCTL > > xen/sysctl: wrap around XEN_SYSCTL_sched_id > > xen/sysctl: wrap around XEN_SYSCTL_perfc_op > > xen/sysctl: wrap around XEN_SYSCTL_lockprof_op > > xen/pmstat: introduce CONFIG_PM_OP > > xen/sysctl: introduce CONFIG_PM_STATS > > xen/sysctl: wrap around XEN_SYSCTL_page_offline_op > > xen/sysctl: wrap around XEN_SYSCTL_cpupool_op > > xen/sysctl: wrap around XEN_SYSCTL_scheduler_op > > xen/sysctl: wrap around XEN_SYSCTL_physinfo > > xen/sysctl: make CONFIG_COVERAGE depend on CONFIG_SYSCTL > > xen/sysctl: make CONFIG_LIVEPATCH depend on CONFIG_SYSCTL > > xen/sysctl: wrap around arch-specific arch_do_sysctl > > When thinking about whether to commit part of the series, it occurred to me > that to > avoid transiently regressing shim (in size), shouldn't the currently 1st > patch be > moved to be 2nd to last, and then be committed together with the last one? In > any > event the plan right now is to commit some patches from the beginning of this > series, but specifically without patch 1. Please shout if you see any problem > with > this.
Understood, fine with me > > Jan
