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 <dpsm...@apertussolutions.com>
>>>> ---
>>>> 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
