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

[Jason Andryuk <jason.andryuk@amd.com>]

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