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

Re: [PATCH 1/6] x86/boot: Rework dom0 feature configuration


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 16 May 2023 13:43:56 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=MWlTigUskYubx+9Zv0iuN3DWlrd8JnghAlmVuc4pw6s=; b=ODgYQJM12MSafds6Dq4MFJ1M+ww9pi1V2XSM10uJqsjsrZgr3zCkKIoLdKsXJgWMm0UgMt4qng5wLcEedd4UfY43kNwW5bSgwhAwhuJiQHgV9tGgE4QF/2Qnqenlf5oHq9EhybPOumxRwhp4xMYDDw6xoFwBpXzSgFkAM6rpEvdCyzN7nRRF5WdpCiIYWXPPikA/nLqogedEsdMqAGtjAtmdPiUs8vuU5HKj7t0igekprSienZ8eQMDORPg+oOK8/T3KEsbZ6KghIts1T+VL7YPu78u/JaCa4h2FsHu1sbOO7amqlOrxRhNtzplfET7AnFyXIj4da83V/6iKxXMcJA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ekjRwIYUH3pqWrs/iH1pt6YyDHmlVKgSEVB6EsdHctNBswM9bsqlg674fVBm6pIE8vYq1zfcxOb6XrGRdPJm38OmMbiF98RNy7Mp66iqV6dNZwk0Syl2P1rKlRonYxh2W2h+v5cUWFzE81aaNGSlS/sfuLK0gzNkiK4LseZ1vQ5lQld4ceRc4N1MgbP+AWwmhRbOCcRl5+UNfQu2yZqMoj8A2/C/kze9146Pr14zZdMvNRVso9g1k7xb5EwZ2UVFfWDfxYxkPOVHz0gYGSWEQg5niRUxcLkYsAGbiODr9RxzwqnlSNG0wmJfX9vbbvb/khJoUvz/Q6Q/ZuTuhaWvmA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 16 May 2023 11:44:25 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.05.2023 11:45, Andrew Cooper wrote:
> On 16/05/2023 8:58 am, Jan Beulich wrote:
>> On 15.05.2023 16:42, Andrew Cooper wrote:
>>> @@ -858,7 +839,7 @@ void __init init_dom0_cpuid_policy(struct domain *d)
>>>       * so dom0 can turn off workarounds as appropriate.  Temporary, until 
>>> the
>>>       * domain policy logic gains a better understanding of MSRs.
>>>       */
>>> -    if ( cpu_has_arch_caps )
>>> +    if ( is_hardware_domain(d) && cpu_has_arch_caps )
>>>          p->feat.arch_caps = true;
>> As a result of this, ...
>>
>>> @@ -876,8 +857,32 @@ void __init init_dom0_cpuid_policy(struct domain *d)
>>>          }
>>>  
>>>          x86_cpu_featureset_to_policy(fs, p);
>>> +    }
>>> +
>>> +    /*
>>> +     * PV Control domains used to require unfiltered CPUID.  This was 
>>> fixed in
>>> +     * Xen 4.13, but there is an cmdline knob to restore the prior 
>>> behaviour.
>>> +     *
>>> +     * If the domain is getting unfiltered CPUID, don't let the guest 
>>> kernel
>>> +     * play with CPUID faulting either, as Xen's CPUID path won't cope.
>>> +     */
>>> +    if ( !opt_dom0_cpuid_faulting && is_control_domain(d) && 
>>> is_pv_domain(d) )
>>> +        p->platform_info.cpuid_faulting = false;
>>>  
>>> -        recalculate_cpuid_policy(d);
>>> +    recalculate_cpuid_policy(d);
>>> +
>>> +    if ( is_hardware_domain(d) && cpu_has_arch_caps )
>> ... it would feel slightly more logical if p->feat.arch_caps was used here.
>> Whether that's to replace the entire condition or merely the right side of
>> the && depends on what the subsequent changes require (which I haven't
>> looked at yet).
> 
> I'd really prefer to leave it as-is.
> 
> You're likely right, but this entire block is deleted in patch 6 and it
> has been a giant pain already making this series bisectable WRT all our
> special cases.
> 
> For the sake of a few patches, it's safer to go with it in the
> pre-existing form.

Oh, sure, if this goes away anyway, then there's not that much point in
making such a change.

Jan



 


Rackspace

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