Wrap domctl hypercall def and domctl.o with CONFIG_MGMT_HYPERCALLS.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
---
v1 -> v2:
- remove stub in common/domctl.c
- combine the original commit of "xen/domctl: provide stub for
domctl_lock_{acquire,release}"
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
---
v2 -> v3:
- add pitfall warnning in Kconfig help
---
xen/common/Kconfig | 6 ++++--
xen/common/Makefile | 2 +-
xen/include/hypercall-defs.c | 4 ++--
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 309d262386..efbe97c54a 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -646,11 +646,13 @@ config SYSTEM_SUSPEND
If unsure, say N.
config MGMT_HYPERCALLS
- def_bool y
+ bool "Enable privileged hypercalls for system management"
help
This option shall only be disabled on some dom0less systems, or
PV shim on x86, to reduce Xen footprint via managing unnessary
- hypercalls, like sysctl, etc.
+ hypercalls, like sysctl, domctl, etc.
+ Be cautious to disable it, as users will face missing a few basic
+ hypercalls like listdomains, getdomaininfo, etc.
config PM_OP
bool "Enable Performance Management Operation"
diff --git a/xen/common/Makefile b/xen/common/Makefile
index fdf826f218..45c0bda000 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -11,7 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
obj-$(CONFIG_DEVICE_TREE_PARSE) += device-tree/
obj-$(CONFIG_IOREQ_SERVER) += dm.o
obj-y += domain.o
-obj-y += domctl.o
+obj-$(CONFIG_MGMT_HYPERCALLS) += domctl.o
obj-y += domid.o
obj-y += event_2l.o
obj-y += event_channel.o
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 02d7b93e80..c243edc460 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -196,11 +196,11 @@ dm_op(domid_t domid, unsigned int nr_bufs, xen_dm_op_buf_t *bufs)
#endif
#ifdef CONFIG_MGMT_HYPERCALLS
sysctl(xen_sysctl_t *u_sysctl)
+domctl(xen_domctl_t *u_domctl)
#endif
#if defined(CONFIG_X86) && defined(CONFIG_PAGING) && defined(CONFIG_MGMT_HYPERCALLS)
paging_domctl_cont(xen_domctl_t *u_domctl)
#endif
-domctl(xen_domctl_t *u_domctl)
#ifndef CONFIG_PV_SHIM_EXCLUSIVE
platform_op(xen_platform_op_t *u_xenpf_op)
#endif
@@ -279,8 +279,8 @@ hvm_op do do do do do
#endif
#ifdef CONFIG_MGMT_HYPERCALLS
sysctl do do do do do
-#endif
domctl do do do do do
+#endif
#ifdef CONFIG_KEXEC
kexec_op compat do - - -
#endif
--
2.34.1On 13.10.2025 12:15, Penny Zheng wrote: > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -646,11 +646,13 @@ config SYSTEM_SUSPEND > If unsure, say N. > > config MGMT_HYPERCALLS > - def_bool y > + bool "Enable privileged hypercalls for system management" > help > This option shall only be disabled on some dom0less systems, or > PV shim on x86, to reduce Xen footprint via managing unnessary > - hypercalls, like sysctl, etc. > + hypercalls, like sysctl, domctl, etc. > + Be cautious to disable it, as users will face missing a few basic > + hypercalls like listdomains, getdomaininfo, etc. This is still too little, imo. For one I'm not sure "users" is quite the right term. I'd say it's more "admins". And then, as mentioned, there are a few domctl-s which are usable by DMs. Aiui device pass-through may also be impacted, which imo will want mentioning here as well. Or else, if there is an implication that DMs aren't to be used when MGMT_HYPERCALLS=n, that is what would want calling out. Jan
[Public]
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, October 30, 2025 9:40 PM
> To: Penny, Zheng <penny.zheng@amd.com>
> Cc: Huang, Ray <Ray.Huang@amd.com>; oleksii.kurochko@gmail.com; Andrew
> Cooper <andrew.cooper3@citrix.com>; Anthony PERARD
> <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>; Julien
> Grall <julien@xen.org>; Roger Pau Monné <roger.pau@citrix.com>; Stefano
> Stabellini <sstabellini@kernel.org>; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with
> CONFIG_MGMT_HYPERCALLS
>
> On 13.10.2025 12:15, Penny Zheng wrote:
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -646,11 +646,13 @@ config SYSTEM_SUSPEND
> > If unsure, say N.
> >
> > config MGMT_HYPERCALLS
> > - def_bool y
> > + bool "Enable privileged hypercalls for system management"
> > help
> > This option shall only be disabled on some dom0less systems, or
> > PV shim on x86, to reduce Xen footprint via managing unnessary
> > - hypercalls, like sysctl, etc.
> > + hypercalls, like sysctl, domctl, etc.
> > + Be cautious to disable it, as users will face missing a few basic
> > + hypercalls like listdomains, getdomaininfo, etc.
>
> This is still too little, imo. For one I'm not sure "users" is quite the right term. I'd say
> it's more "admins". And then, as mentioned, there are a few domctl-s which are
> usable by DMs. Aiui device pass-through may also be impacted, which imo will
> want mentioning here as well. Or else, if there is an implication that DMs aren't to
> be used when MGMT_HYPERCALLS=n, that is what would want calling out.
>
How about
"
Be cautious to disable it, as admins will face missing a few basic
hypercalls like listdomains, getdomaininfo, etc, hence leading to
have an impact on xl-device-passthrough and restricted DM.
"
Another question on PV_SHIM_EXCLUSIVE:
After Stefano's " 6c80f0dd1bb xen: fix randconfig build problems after introducing SYSCTL " reversion patch, and to avoid incurring randconfig failures till the last, maybe I shall combine all PV_SHIM_EXCLUSIVE-related changes into a new commit and put it in the last, after making MGMT_HYPERCALLS optional again?
> Jan
On 18.11.2025 07:43, Penny, Zheng wrote: > [Public] > >> -----Original Message----- >> From: Jan Beulich <jbeulich@suse.com> >> Sent: Thursday, October 30, 2025 9:40 PM >> To: Penny, Zheng <penny.zheng@amd.com> >> Cc: Huang, Ray <Ray.Huang@amd.com>; oleksii.kurochko@gmail.com; Andrew >> Cooper <andrew.cooper3@citrix.com>; Anthony PERARD >> <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>; Julien >> Grall <julien@xen.org>; Roger Pau Monné <roger.pau@citrix.com>; Stefano >> Stabellini <sstabellini@kernel.org>; xen-devel@lists.xenproject.org >> Subject: Re: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with >> CONFIG_MGMT_HYPERCALLS >> >> On 13.10.2025 12:15, Penny Zheng wrote: >>> --- a/xen/common/Kconfig >>> +++ b/xen/common/Kconfig >>> @@ -646,11 +646,13 @@ config SYSTEM_SUSPEND >>> If unsure, say N. >>> >>> config MGMT_HYPERCALLS >>> - def_bool y >>> + bool "Enable privileged hypercalls for system management" >>> help >>> This option shall only be disabled on some dom0less systems, or >>> PV shim on x86, to reduce Xen footprint via managing unnessary >>> - hypercalls, like sysctl, etc. >>> + hypercalls, like sysctl, domctl, etc. >>> + Be cautious to disable it, as users will face missing a few basic >>> + hypercalls like listdomains, getdomaininfo, etc. >> >> This is still too little, imo. For one I'm not sure "users" is quite the right term. I'd say >> it's more "admins". And then, as mentioned, there are a few domctl-s which are >> usable by DMs. Aiui device pass-through may also be impacted, which imo will >> want mentioning here as well. Or else, if there is an implication that DMs aren't to >> be used when MGMT_HYPERCALLS=n, that is what would want calling out. > > How about > " > Be cautious to disable it, as admins will face missing a few basic > hypercalls like listdomains, getdomaininfo, etc, hence leading to > have an impact on xl-device-passthrough and restricted DM. > " Much better. However, why "xl-" and why "restricted"? Neither aspect matters here, unless I overlook something. > Another question on PV_SHIM_EXCLUSIVE: > After Stefano's " 6c80f0dd1bb xen: fix randconfig build problems after introducing SYSCTL " reversion patch, and to avoid incurring randconfig failures till the last, maybe I shall combine all PV_SHIM_EXCLUSIVE-related changes into a new commit and put it in the last, after making MGMT_HYPERCALLS optional again? Whatever works best. Jan
[Public] > -----Original Message----- > From: Jan Beulich <jbeulich@suse.com> > Sent: Tuesday, November 18, 2025 3:14 PM > To: Penny, Zheng <penny.zheng@amd.com> > Cc: Huang, Ray <Ray.Huang@amd.com>; oleksii.kurochko@gmail.com; Andrew > Cooper <andrew.cooper3@citrix.com>; Anthony PERARD > <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>; Julien > Grall <julien@xen.org>; Roger Pau Monné <roger.pau@citrix.com>; Stefano > Stabellini <sstabellini@kernel.org>; xen-devel@lists.xenproject.org > Subject: Re: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with > CONFIG_MGMT_HYPERCALLS > > On 18.11.2025 07:43, Penny, Zheng wrote: > > [Public] > > > >> -----Original Message----- > >> From: Jan Beulich <jbeulich@suse.com> > >> Sent: Thursday, October 30, 2025 9:40 PM > >> To: Penny, Zheng <penny.zheng@amd.com> > >> Cc: Huang, Ray <Ray.Huang@amd.com>; oleksii.kurochko@gmail.com; > >> Andrew Cooper <andrew.cooper3@citrix.com>; Anthony PERARD > >> <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>; > >> Julien Grall <julien@xen.org>; Roger Pau Monné > >> <roger.pau@citrix.com>; Stefano Stabellini <sstabellini@kernel.org>; > >> xen-devel@lists.xenproject.org > >> Subject: Re: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with > >> CONFIG_MGMT_HYPERCALLS > >> > >> On 13.10.2025 12:15, Penny Zheng wrote: > >>> --- a/xen/common/Kconfig > >>> +++ b/xen/common/Kconfig > >>> @@ -646,11 +646,13 @@ config SYSTEM_SUSPEND > >>> If unsure, say N. > >>> > >>> config MGMT_HYPERCALLS > >>> - def_bool y > >>> + bool "Enable privileged hypercalls for system management" > >>> help > >>> This option shall only be disabled on some dom0less systems, or > >>> PV shim on x86, to reduce Xen footprint via managing unnessary > >>> - hypercalls, like sysctl, etc. > >>> + hypercalls, like sysctl, domctl, etc. > >>> + Be cautious to disable it, as users will face missing a few basic > >>> + hypercalls like listdomains, getdomaininfo, etc. > >> > >> This is still too little, imo. For one I'm not sure "users" is quite > >> the right term. I'd say it's more "admins". And then, as mentioned, > >> there are a few domctl-s which are usable by DMs. Aiui device > >> pass-through may also be impacted, which imo will want mentioning > >> here as well. Or else, if there is an implication that DMs aren't to be used when > MGMT_HYPERCALLS=n, that is what would want calling out. > > > > How about > > " > > Be cautious to disable it, as admins will face missing a few basic > > hypercalls like listdomains, getdomaininfo, etc, hence leading to > > have an impact on xl-device-passthrough and restricted DM. > > " > > Much better. However, why "xl-" and why "restricted"? Neither aspect matters here, > unless I overlook something. > Later, in hyperlaunch scenario, device passthrough is still needed, but it's not current device passthrough mode, which depends on xl-tool-stack to de-assign it from hardware domain and re-assign it to guest. It will be limited in boot-up stage, and configured via device tree only. FWIU, we may reuse VPCI framework, but commands like "xl assign/deassign xxx" will not be needed anymore. PLZ correct me if understand wrongly, @Andryuk, Jason And DM, like QEMU, is still applicable, but only supports a new machine type, "pvh". If it is too much details and only brings confusion, I'll delete and refine it to " have an impact on device-passthrough and DM " > > Another question on PV_SHIM_EXCLUSIVE: > > After Stefano's " 6c80f0dd1bb xen: fix randconfig build problems after introducing > SYSCTL " reversion patch, and to avoid incurring randconfig failures till the last, > maybe I shall combine all PV_SHIM_EXCLUSIVE-related changes into a new > commit and put it in the last, after making MGMT_HYPERCALLS optional again? > > Whatever works best. > > Jan
On 2025-11-18 02:51, Penny, Zheng wrote: > [Public] > >> -----Original Message----- >> From: Jan Beulich <jbeulich@suse.com> >> Sent: Tuesday, November 18, 2025 3:14 PM >> To: Penny, Zheng <penny.zheng@amd.com> >> Cc: Huang, Ray <Ray.Huang@amd.com>; oleksii.kurochko@gmail.com; Andrew >> Cooper <andrew.cooper3@citrix.com>; Anthony PERARD >> <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>; Julien >> Grall <julien@xen.org>; Roger Pau Monné <roger.pau@citrix.com>; Stefano >> Stabellini <sstabellini@kernel.org>; xen-devel@lists.xenproject.org >> Subject: Re: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with >> CONFIG_MGMT_HYPERCALLS >> >> On 18.11.2025 07:43, Penny, Zheng wrote: >>> [Public] >>> >>>> -----Original Message----- >>>> From: Jan Beulich <jbeulich@suse.com> >>>> Sent: Thursday, October 30, 2025 9:40 PM >>>> To: Penny, Zheng <penny.zheng@amd.com> >>>> Cc: Huang, Ray <Ray.Huang@amd.com>; oleksii.kurochko@gmail.com; >>>> Andrew Cooper <andrew.cooper3@citrix.com>; Anthony PERARD >>>> <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>; >>>> Julien Grall <julien@xen.org>; Roger Pau Monné >>>> <roger.pau@citrix.com>; Stefano Stabellini <sstabellini@kernel.org>; >>>> xen-devel@lists.xenproject.org >>>> Subject: Re: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with >>>> CONFIG_MGMT_HYPERCALLS >>>> >>>> On 13.10.2025 12:15, Penny Zheng wrote: >>>>> --- a/xen/common/Kconfig >>>>> +++ b/xen/common/Kconfig >>>>> @@ -646,11 +646,13 @@ config SYSTEM_SUSPEND >>>>> If unsure, say N. >>>>> >>>>> config MGMT_HYPERCALLS >>>>> - def_bool y >>>>> + bool "Enable privileged hypercalls for system management" >>>>> help >>>>> This option shall only be disabled on some dom0less systems, or >>>>> PV shim on x86, to reduce Xen footprint via managing unnessary "unnecessary" >>>>> - hypercalls, like sysctl, etc. >>>>> + hypercalls, like sysctl, domctl, etc. >>>>> + Be cautious to disable it, as users will face missing a few basic >>>>> + hypercalls like listdomains, getdomaininfo, etc. >>>> >>>> This is still too little, imo. For one I'm not sure "users" is quite >>>> the right term. I'd say it's more "admins". And then, as mentioned, >>>> there are a few domctl-s which are usable by DMs. Aiui device >>>> pass-through may also be impacted, which imo will want mentioning >>>> here as well. Or else, if there is an implication that DMs aren't to be used when >> MGMT_HYPERCALLS=n, that is what would want calling out. >>> >>> How about >>> " >>> Be cautious to disable it, as admins will face missing a few basic >>> hypercalls like listdomains, getdomaininfo, etc, hence leading to >>> have an impact on xl-device-passthrough and restricted DM. >>> " >> >> Much better. However, why "xl-" and why "restricted"? Neither aspect matters here, >> unless I overlook something. >> > > Later, in hyperlaunch scenario, device passthrough is still needed, but it's not current device passthrough mode, which depends on xl-tool-stack to de-assign it from hardware domain and re-assign it to guest. It will be limited in boot-up stage, and configured via device tree only. FWIU, we may reuse VPCI framework, but commands like "xl assign/deassign xxx" will not be needed anymore. PLZ correct me if understand wrongly, @Andryuk, Jason Yes, this is correct. > > And DM, like QEMU, is still applicable, but only supports a new machine type, "pvh". vPCI is used to assign the PCI devices to a PVH domain during boot. QEMU is present and provides virtio devices, but it does not play a role in PCI passthrough. So far we've used independent PCI segments for vPCI and QEMU/virtio. Anyway, maybe something like this for the help text: """ Management hypercalls provide the means for dom0 to manage the overall Xen system and other domains. This includes the hypercalls needed to construct new domains. In a dom0less or pv-shim build, they can be omitted to cut down on the Xen binary's size. However, this comes at the loss of significant runtime functionality. Unless you know what you are doing, you should enable this. """ Regards, Jason
[Public] > -----Original Message----- > From: Jason Andryuk <jason.andryuk@amd.com> > Sent: Wednesday, November 19, 2025 3:30 AM > To: Penny, Zheng <penny.zheng@amd.com>; Jan Beulich <jbeulich@suse.com> > Cc: Huang, Ray <Ray.Huang@amd.com>; oleksii.kurochko@gmail.com; Andrew > Cooper <andrew.cooper3@citrix.com>; Anthony PERARD > <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>; Julien > Grall <julien@xen.org>; Roger Pau Monné <roger.pau@citrix.com>; Stefano > Stabellini <sstabellini@kernel.org>; xen-devel@lists.xenproject.org > Subject: Re: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with > CONFIG_MGMT_HYPERCALLS > > On 2025-11-18 02:51, Penny, Zheng wrote: > > [Public] > > > >> -----Original Message----- > >> From: Jan Beulich <jbeulich@suse.com> > >> Sent: Tuesday, November 18, 2025 3:14 PM > >> To: Penny, Zheng <penny.zheng@amd.com> > >> Cc: Huang, Ray <Ray.Huang@amd.com>; oleksii.kurochko@gmail.com; > >> Andrew Cooper <andrew.cooper3@citrix.com>; Anthony PERARD > >> <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>; > >> Julien Grall <julien@xen.org>; Roger Pau Monné > >> <roger.pau@citrix.com>; Stefano Stabellini <sstabellini@kernel.org>; > >> xen-devel@lists.xenproject.org > >> Subject: Re: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with > >> CONFIG_MGMT_HYPERCALLS > >> > >> On 18.11.2025 07:43, Penny, Zheng wrote: > >>> [Public] > >>> > >>>> -----Original Message----- > >>>> From: Jan Beulich <jbeulich@suse.com> > >>>> Sent: Thursday, October 30, 2025 9:40 PM > >>>> To: Penny, Zheng <penny.zheng@amd.com> > >>>> Cc: Huang, Ray <Ray.Huang@amd.com>; oleksii.kurochko@gmail.com; > >>>> Andrew Cooper <andrew.cooper3@citrix.com>; Anthony PERARD > >>>> <anthony.perard@vates.tech>; Orzel, Michal <Michal.Orzel@amd.com>; > >>>> Julien Grall <julien@xen.org>; Roger Pau Monné > >>>> <roger.pau@citrix.com>; Stefano Stabellini > >>>> <sstabellini@kernel.org>; xen-devel@lists.xenproject.org > >>>> Subject: Re: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with > >>>> CONFIG_MGMT_HYPERCALLS > >>>> > >>>> On 13.10.2025 12:15, Penny Zheng wrote: > >>>>> --- a/xen/common/Kconfig > >>>>> +++ b/xen/common/Kconfig > >>>>> @@ -646,11 +646,13 @@ config SYSTEM_SUSPEND > >>>>> If unsure, say N. > >>>>> > >>>>> config MGMT_HYPERCALLS > >>>>> - def_bool y > >>>>> + bool "Enable privileged hypercalls for system management" > >>>>> help > >>>>> This option shall only be disabled on some dom0less systems, or > >>>>> PV shim on x86, to reduce Xen footprint via managing > >>>>> unnessary > > "unnecessary" > > >>>>> - hypercalls, like sysctl, etc. > >>>>> + hypercalls, like sysctl, domctl, etc. > >>>>> + Be cautious to disable it, as users will face missing a few basic > >>>>> + hypercalls like listdomains, getdomaininfo, etc. > >>>> > >>>> This is still too little, imo. For one I'm not sure "users" is > >>>> quite the right term. I'd say it's more "admins". And then, as > >>>> mentioned, there are a few domctl-s which are usable by DMs. Aiui > >>>> device pass-through may also be impacted, which imo will want > >>>> mentioning here as well. Or else, if there is an implication that > >>>> DMs aren't to be used when > >> MGMT_HYPERCALLS=n, that is what would want calling out. > >>> > >>> How about > >>> " > >>> Be cautious to disable it, as admins will face missing a few basic > >>> hypercalls like listdomains, getdomaininfo, etc, hence leading to > >>> have an impact on xl-device-passthrough and restricted DM. > >>> " > >> > >> Much better. However, why "xl-" and why "restricted"? Neither aspect > >> matters here, unless I overlook something. > >> > > > > Later, in hyperlaunch scenario, device passthrough is still needed, > > but it's not current device passthrough mode, which depends on > > xl-tool-stack to de-assign it from hardware domain and re-assign it to > > guest. It will be limited in boot-up stage, and configured via device > > tree only. FWIU, we may reuse VPCI framework, but commands like "xl > > assign/deassign xxx" will not be needed anymore. PLZ correct me if > > understand wrongly, @Andryuk, Jason > > Yes, this is correct. > > > > > And DM, like QEMU, is still applicable, but only supports a new machine type, > "pvh". > > vPCI is used to assign the PCI devices to a PVH domain during boot. > QEMU is present and provides virtio devices, but it does not play a role in PCI > passthrough. So far we've used independent PCI segments for vPCI and > QEMU/virtio. > > Anyway, maybe something like this for the help text: > """ > Management hypercalls provide the means for dom0 to manage the overall Xen > system and other domains. This includes the hypercalls needed to construct new > domains. In a dom0less or pv-shim build, they can be omitted to cut down on the > Xen binary's size. However, this comes at the loss of significant runtime > functionality. > > Unless you know what you are doing, you should enable this. > """ > Thx!!! I'll combine them all > Regards, > Jason
© 2016 - 2026 Red Hat, Inc.