Re: [RFC 04/38] x86/hyperlaunch: convert vcpu0 creation to domain builder

[Alejandro Vallejo <agarciav@xxxxxxx>]

On Fri Apr 25, 2025 at 11:04 PM BST, Daniel P. Smith wrote:
> On 4/25/25 11:22, Alejandro Vallejo wrote:
>> On Sat Apr 19, 2025 at 11:07 PM BST, Daniel P. Smith wrote:
>>> Convert alloc_dom0_vcpu0() to dom0_set_affinity(), making it only set up the
>>> node affinity based on command line parameters passed. At the same time,
>>> introduce alloc_dom_vcpu0() as the replacement for alloc_dom0_vcpu(). Then 
>>> have
>>> alloc_dom_vcpu0() call dom0_set_affinity() when the boot domain is the 
>>> control
>>> domain, otherwise set the affinity to auto.
>>>
>>> Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
>>> ---
>>>   xen/arch/x86/dom0_build.c                 |  4 +---
>>>   xen/arch/x86/domain-builder/domain.c      | 11 +++++++++++
>>>   xen/arch/x86/include/asm/dom0_build.h     |  2 ++
>>>   xen/arch/x86/include/asm/domain-builder.h |  1 +
>>>   xen/arch/x86/setup.c                      |  5 +++--
>>>   5 files changed, 18 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/domain-builder/domain.c 
>>> b/xen/arch/x86/domain-builder/domain.c
>>> index f2277b9e3cf3..619d36ea0b87 100644
>>> --- a/xen/arch/x86/domain-builder/domain.c
>>> +++ b/xen/arch/x86/domain-builder/domain.c
>>> @@ -9,6 +9,7 @@
>>>   #include <xen/sched.h>
>>>   
>>>   #include <asm/bootinfo.h>
>>> +#include <asm/dom0_build.h>
>>>   
>>>   unsigned int __init dom_max_vcpus(struct boot_domain *bd)
>>>   {
>>> @@ -27,6 +28,16 @@ unsigned int __init dom_max_vcpus(struct boot_domain *bd)
>>>       return bd->max_vcpus;
>>>   }
>>>   
>>> +struct vcpu *__init alloc_dom_vcpu0(struct boot_domain *bd)
>>> +{
>>> +    if ( bd->capabilities & BUILD_CAPS_CONTROL )
>>> +        dom0_set_affinity(bd->d);
>> 
>> Similar as before, this probably wants to be DOMAIN_CAPS_HARDWARE?
>> 
>> I'll adjust while rebasing.
>
> Does it?
>
> v/r,
> dps

The situation is similar later on when choosing a CPU policy. Why
mustn't the hardware domain get the same treatment as the control
domains? Using (DOMAIN_CAPS_CONTROL | DOMAIN_CAPS_HARDWARE) at the
very least seems warranted.

All these cases single-out dom0 when dom0 is both a control and a
hardware domain, but as Jason mentioned how is Xen meant to deal with
dom0_X arguments when dom0 is disaggregated? Either it applies to all
its constituents (with the plausible exception of a xenstore domain), or
just one (the hardware domain), or none. Only applying to control
domains and not the hardware domain doesn't look right (to me).

Cheers,
Alejandro