[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86: Conditionalise init_dom0_cpu_policy()


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
  • Date: Wed, 30 Jul 2025 11:48:29 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fa0epT7yl3dFM2zLVtXhAd7laGTEas+C52HF9W0K+Os=; b=uqXsaMeGmCUS13WjRjgpsfiTNJOC9cWNpdZvBH/YBQ2t+7g1J2Cvd9kceuI39dGJnDa2Xs9DM+l5PXV4n5UyvJp2JNdFuv8MFl/9ARky0+RyqxgIaLL3mkLGSxU5ofSI/+g5f7HRDJhcjin/RkSDVeUs/wMFdEQGXjbe/SHJw63moVjPE6T0yP23T5gz7WOU1eMZwToxkvh1bWLuIB4g76BU5JgwAvnm/RG/z+ilUeAYpW0/inLIlSMw60pemAtbWZFFzorp9JqGdJl48K6lZ77P0oGLe+lQA6GZPLcwkJG7wCojOY9tigrw1YZRLIA5jcsDHKW4R7qnu6p9U8mgZg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FIJMcj8M2jfZXhk+wldfmAAP5b9xQboHHgVil9JXwHG+vN67/EbY9/66V1kjDACf4YeMsOfm3yNsJNaK/msUYtCfuCt2RlnsfKbLtR24WtwEgjYF6UZpsL+UcS7tyYdXGZIx0Oxo2K4dFAh25mw3lml1XU+T5rnfb4tu3+Nkke4IwQ/CvjtsdgJozl7Zt+dIcLeadmmt5ZuH3/glHZSTC6JHE6vhAm8jEj6e4lVN6mgxclbrtXO8Y7h+dRedXOU2bMCD8ttdPsbAQKGxs7cCkVkecKaSP95B4I2aKWU/QZuTgY7XWpQtMQkmBuxqS38Smq+HuRbW1VvvCnsJxXmdjw==
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Wed, 30 Jul 2025 09:48:46 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.
>
> Jan

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?

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.

There's exceptions. nmi=dom0 should be renamed to nmi=hwdom (if anything,
because that's exactly what it does even with late hwdom), but anything with
dom0_X ought to be ignored. Which implies first and foremost moving its uses
outside domain construction and general use.

All dom0_ options ought to be parsed and used from __init functions before
construct_dom0(), and construct_dom0 ought to depend strictly on information
in boot_domain + domain.

Only then we'll have sanity.

Cheers
Alejandro



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.