RE: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with CONFIG_MGMT_HYPERCALLS

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

[Public]

> -----Original Message-----
> From: Jason Andryuk <jason.andryuk@xxxxxxx>
> Sent: Wednesday, November 19, 2025 3:30 AM
> To: Penny, Zheng <penny.zheng@xxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; oleksii.kurochko@xxxxxxxxx; Andrew
> Cooper <andrew.cooper3@xxxxxxxxxx>; Anthony PERARD
> <anthony.perard@xxxxxxxxxx>; Orzel, Michal <Michal.Orzel@xxxxxxx>; Julien
> Grall <julien@xxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>; Stefano
> Stabellini <sstabellini@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxx>
> >> Sent: Tuesday, November 18, 2025 3:14 PM
> >> To: Penny, Zheng <penny.zheng@xxxxxxx>
> >> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; oleksii.kurochko@xxxxxxxxx;
> >> Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Anthony PERARD
> >> <anthony.perard@xxxxxxxxxx>; Orzel, Michal <Michal.Orzel@xxxxxxx>;
> >> Julien Grall <julien@xxxxxxx>; Roger Pau Monné
> >> <roger.pau@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>;
> >> xen-devel@xxxxxxxxxxxxxxxxxxxx
> >> 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@xxxxxxxx>
> >>>> Sent: Thursday, October 30, 2025 9:40 PM
> >>>> To: Penny, Zheng <penny.zheng@xxxxxxx>
> >>>> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; oleksii.kurochko@xxxxxxxxx;
> >>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Anthony PERARD
> >>>> <anthony.perard@xxxxxxxxxx>; Orzel, Michal <Michal.Orzel@xxxxxxx>;
> >>>> Julien Grall <julien@xxxxxxx>; Roger Pau Monné
> >>>> <roger.pau@xxxxxxxxxx>; Stefano Stabellini
> >>>> <sstabellini@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> >>>> 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