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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx>
> > Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
> > ---
> >   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.

In any case, I think the strategy should apply to all architectures.