Re: [PATCH] x86: Conditionalise init_dom0_cpu_policy()

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

On Wed Jul 30, 2025 at 11:58 AM CEST, Jan Beulich wrote:
> On 30.07.2025 11:48, Alejandro Vallejo wrote:
>> On Wed Jul 30, 2025 at 9:48 AM CEST, Jan Beulich wrote:
>>> On 29.07.2025 23:29, Daniel P. Smith wrote:
>>>> On 7/25/25 06:56, Roger Pau Monné wrote:
>>>>> On Fri, Jul 25, 2025 at 12:02:18PM +0200, Alejandro Vallejo wrote:
>>>>>> On Wed Jul 23, 2025 at 9:18 AM CEST, Roger Pau Monné wrote:
>>>>>>> On Thu, Jul 17, 2025 at 07:58:24PM +0200, Alejandro Vallejo wrote:
>>>>>>>> Later patches will keep refactoring create_dom0()
>>>>>>>> until it can create arbitrary domains. This is one
>>>>>>>> small step in that direction.
>>>>>>>>
>>>>>>>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
>>>>>>>> ---
>>>>>>>>   xen/arch/x86/setup.c | 3 ++-
>>>>>>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>>>>>>> index c6890669b9..6943ffba79 100644
>>>>>>>> --- a/xen/arch/x86/setup.c
>>>>>>>> +++ b/xen/arch/x86/setup.c
>>>>>>>> @@ -1054,7 +1054,8 @@ static struct domain *__init create_dom0(struct 
>>>>>>>> boot_info *bi)
>>>>>>>>       if ( IS_ERR(d) )
>>>>>>>>           panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
>>>>>>>>   
>>>>>>>> -    init_dom0_cpuid_policy(d);
>>>>>>>> +    if ( pv_shim || d->cdf & (CDF_privileged | CDF_hardware) )
>>>>>>>
>>>>>>> You possibly want this to be:
>>>>>>>
>>>>>>> (d->cdf & (CDF_privileged | CDF_hardware)) == (CDF_privileged | 
>>>>>>> CDF_hardware)
>>>>>>>
>>>>>>> To ensure the contents of dom0_cpuid_cmdline is only applied to dom0,
>>>>>>> and not to the hardware or control domains.  I assume it should be
>>>>>>> possible to pass a different set of cpuid options for the hardware vs
>>>>>>> the control domains.
>>>>>>>
>>>>>>> Thanks, Roger.
>>>>>>
>>>>>> Why only a hwdom+ctldom, surely a single hwdom should get it too.
>>>>>
>>>>> hm, not really I think: a late hardware domain would get any custom
>>>>> cpuid options from the toolstack that created it, or in the
>>>>> hyperlaunch case from the provided configuration, but not from the
>>>>> dom0-cpuid command line option I would expect.  Otherwise you have two
>>>>> different sources of cpuid options, the inheritance from dom0-cpuid,
>>>>> plus whatever is provided from the hardware domain configuration.
>>>>
>>>> Yes, this has been a sticking point for me and never got any good 
>>>> answers thus far. Should the dom0 related xen command line options only 
>>>> apply when not booting via hyperlaunch. If the answer is no, then you're 
>>>> in this area with some dom0 options that really are applicable to hwdom 
>>>> vs ctldom and vice-a-versa. Some could even be suggested to apply to 
>>>> both. And then, I don't believe there really is a consensus one which 
>>>> options apply to which domains. Over the years working on this, I have 
>>>> been an advocate that commandline adjustments allow for quicker 
>>>> troubleshooting by the user/administrator.
>> 
>>>> In the last version of the multidomain construction RFC, I am growing more
>>>> and more to advocate for my initial proposition, that dom0 options only
>>>> apply when not using  hyperlaunch.
>> 
>> I agree. It simplifies everything a ton, and it's far less confusing to know
>> ultimate settings, which in a predefined initial system definition is 
>> important.
>> 
>>>
>>> With the hyperlaunch plans, is there something that's still properly
>>> "Dom0", perhaps under certain conditions? That (and only that) is
>>> where I would see respective command line options to apply. IOW no
>>> more than one specific domain (i.e. in particular not to both hwdom
>>> and ctldom, when they're separate). In cases when respective options
>>> are entirely ignored, I think some kind of warning would want issuing.
>> 
>> The problem is that lines are blurred. A ctldtdom + hwdom + xsdom with domid0
>> is clearly a dom0. Is it still a dom0 when there's no xenstore? What about 
>> when
>> it's not privileged? What about a ctldom + hwdom + xsdom with domid3? What 
>> about
>> dom0_mem options when some domains have already been constructed and 
>> available
>> memory is less than total host memory?
>
> Well, this is what needs determining before we actually move in any (unclear)
> direction. And we need to keep in mind that people used to infer certain
> things from domain ID being 0. 
>
>> Also if a domain is or isn't dom0 depending on whether a certain other domain
>> exists makes things confusing. You have a DTB+commandline and get a 
>> behaviour,
>> then add a domain and you get another behaviour on the first one, even when 
>> you
>> didn't touch its configuration.
>> 
>> My general view after a while experimenting with the full series is to _not_ 
>> use
>> the dom0 command line, as Daniel mentions. The simplifying effect of not 
>> looking
>> at (e.g) dom0_mem is staggering.
>
> Which likely would imply not to create any domain with ID 0.
>
> Jan

I'm currently of that opinion as well, but that doesn't preclude that the
codebase must stop assuming there _is_ a dom0. There might not be any, or it
might not have domid 0. The scheduler, the io bitmap setter and some late hwdom
code still assume domids.

I have some patches to fix at least _that_ side of the situation, but I haven't
had time to test them in any credible form.

The fact that dom0 construction logic should not be looking at opt_* variables
still stands, IMO.

Cheers,
Alejandro