RE: [PATCH v5 00/18] xen: introduce CONFIG_SYSCTL

["Penny, Zheng" <penny.zheng@xxxxxxx>]

[Public]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Thursday, June 26, 2025 11:51 PM
> To: Penny, Zheng <penny.zheng@xxxxxxx>
> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>;
> Anthony PERARD <anthony.perard@xxxxxxxxxx>; Orzel, Michal
> <Michal.Orzel@xxxxxxx>; Julien Grall <julien@xxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>; 
> Dario
> Faggioli <dfaggioli@xxxxxxxx>; Juergen Gross <jgross@xxxxxxxx>; George
> Dunlap <gwd@xxxxxxxxxxxxxx>; Nathan Studer <nathan.studer@xxxxxxxxxxxxxxx>;
> Stewart Hildebrand <stewart@xxxxxxx>; Bertrand Marquis
> <bertrand.marquis@xxxxxxx>; Volodymyr Babchuk
> <Volodymyr_Babchuk@xxxxxxxx>; Alistair Francis <alistair.francis@xxxxxxx>;
> Bob Eshleman <bobbyeshleman@xxxxxxxxx>; Connor Davis
> <connojdavis@xxxxxxxxx>; Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxx
> 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@xxxxxxxx)
> >
> > 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