[Public] > -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: Thursday, June 26, 2025 11:51 PM > To: Penny, Zheng <penny.zh...@amd.com> > Cc: Huang, Ray <ray.hu...@amd.com>; Andrew Cooper > <andrew.coop...@citrix.com>; Roger Pau Monné <roger....@citrix.com>; > Anthony PERARD <anthony.per...@vates.tech>; Orzel, Michal > <michal.or...@amd.com>; Julien Grall <jul...@xen.org>; Stefano Stabellini > <sstabell...@kernel.org>; Daniel P. Smith <dpsm...@apertussolutions.com>; > Dario > Faggioli <dfaggi...@suse.com>; Juergen Gross <jgr...@suse.com>; George > Dunlap <g...@xenproject.org>; Nathan Studer <nathan.stu...@dornerworks.com>; > Stewart Hildebrand <stew...@stew.dk>; Bertrand Marquis > <bertrand.marq...@arm.com>; Volodymyr Babchuk > <volodymyr_babc...@epam.com>; Alistair Francis <alistair.fran...@wdc.com>; > Bob Eshleman <bobbyeshle...@gmail.com>; Connor Davis > <connojda...@gmail.com>; Oleksii Kurochko <oleksii.kuroc...@gmail.com>; xen- > de...@lists.xenproject.org; xen-de...@dornerworks.com > 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 > > i...@epam.com) > > > > 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
