Re: [PATCH 2/2] x86: generalise vcpu0 creation for a domain

[Jan Beulich <jbeulich@suse.com>]

On 18.07.2025 02:04, Stefano Stabellini wrote:
> On Thu, 17 Jul 2025, Jason Andryuk wrote:
>> On 2025-07-17 13:51, Alejandro Vallejo wrote:
>>> Make alloc_dom0_vcpu0() viable as a general vcpu0 allocator. Keep
>>> behaviour on any hwdom/ctldom identical to that dom0 used to have, and
>>> make non-dom0 have auto node affinity.
>>>
>>> Rename the function to alloc_dom_vcpu0() to reflect this change in
>>> scope, and move the prototype to asm/domain.h from xen/domain.h as it's
>>> only used in x86.
>>>
>>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
>>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>>> ---
>>>   xen/arch/x86/dom0_build.c             | 12 ++++++++----
>>>   xen/arch/x86/include/asm/dom0_build.h |  5 +++++
>>>   xen/arch/x86/setup.c                  |  6 ++++--
>>>   xen/include/xen/domain.h              |  1 -
>>>   4 files changed, 17 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
>>> index 0b467fd4a4..dfae7f888f 100644
>>> --- a/xen/arch/x86/dom0_build.c
>>> +++ b/xen/arch/x86/dom0_build.c
>>> @@ -254,12 +254,16 @@ unsigned int __init dom0_max_vcpus(void)
>>>       return max_vcpus;
>>>   }
>>>   -struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
>>> +struct vcpu *__init alloc_dom_vcpu0(struct domain *d)
>>>   {
>>> -    dom0->node_affinity = dom0_nodes;
>>> -    dom0->auto_node_affinity = !dom0_nr_pxms;
>>> +    d->auto_node_affinity = true;
>>> +    if ( is_hardware_domain(d) || is_control_domain(d) )
>>
>> Do we want dom0 options to apply to:
>> hardware or control
>> just hardware
>> just dom0 (hardware && control && xenstore)
>>
>> ?
>>
>> I think "just dom0" may make the most sense.  My next preference is just
>> hardware.  Control I think should be mostly a domU except for having
>> is_privileged = true;
> 
> Great question. Certainly dom0 options, such as dom0_mem, should not
> apply to Control, and certainly they should apply to regular Dom0.
> 
> The interesting question is whether they should apply to the Hardware
> Domain. Some of the Dom0 options make sense for the Hardware Domain and
> there isn't an equivalent config option available via Dom0less bindings.
> I am not thinking about the dom0_* options but things like nmi=dom0. For
> simplicity and ease of use I would say they should apply to the Hardware
> Domain.

Interesting indeed. So far we more or less aliased hwdom == dom0.

Jan