[Public] > -----Original Message----- > From: Jan Beulich <[email protected]> > Sent: Tuesday, November 18, 2025 3:14 PM > To: Penny, Zheng <[email protected]> > Cc: Huang, Ray <[email protected]>; [email protected]; Andrew > Cooper <[email protected]>; Anthony PERARD > <[email protected]>; Orzel, Michal <[email protected]>; Julien > Grall <[email protected]>; Roger Pau Monné <[email protected]>; Stefano > Stabellini <[email protected]>; [email protected] > 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 <[email protected]> > >> Sent: Thursday, October 30, 2025 9:40 PM > >> To: Penny, Zheng <[email protected]> > >> Cc: Huang, Ray <[email protected]>; [email protected]; > >> Andrew Cooper <[email protected]>; Anthony PERARD > >> <[email protected]>; Orzel, Michal <[email protected]>; > >> Julien Grall <[email protected]>; Roger Pau Monné > >> <[email protected]>; Stefano Stabellini <[email protected]>; > >> [email protected] > >> 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
