[Public]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, June 26, 2025 11:51 PM
> To: Penny, Zheng <penny.zheng@amd.com>
> Cc: Huang, Ray <Ray.Huang@amd.com>; Andrew Cooper
> <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com>;
> Anthony PERARD <anthony.perard@vates.tech>; Orzel, Michal
> <Michal.Orzel@amd.com>; Julien Grall <julien@xen.org>; Stefano Stabellini
> <sstabellini@kernel.org>; Daniel P. Smith <dpsmith@apertussolutions.com>; Dario
> Faggioli <dfaggioli@suse.com>; Juergen Gross <jgross@suse.com>; George
> Dunlap <gwd@xenproject.org>; Nathan Studer <nathan.studer@dornerworks.com>;
> Stewart Hildebrand <stewart@stew.dk>; Bertrand Marquis
> <bertrand.marquis@arm.com>; Volodymyr Babchuk
> <Volodymyr_Babchuk@epam.com>; Alistair Francis <alistair.francis@wdc.com>;
> Bob Eshleman <bobbyeshleman@gmail.com>; Connor Davis
> <connojdavis@gmail.com>; Oleksii Kurochko <oleksii.kurochko@gmail.com>; xen-
> devel@lists.xenproject.org; xen-devel@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
> > ik@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