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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.04.2025 12:33, Alejandro Vallejo wrote:
> 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),

This one-fits-all seems very unlikely to me to make sense, while

> or just one (the hardware domain), or none.

... either of these would. "None" in particular might if all config
information is coming from e.g. DT anyway in such an setup.

> Only applying to control
> domains and not the hardware domain doesn't look right (to me).

+1

Jan