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

Re: [PATCH v5 2/3] amd/msr: allow passthrough of VIRT_SPEC_CTRL for HVM guests


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 17 May 2022 16:46:44 +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=SZ4StM5I8P4/Hrtr+HHrySuBxmRpRNklggJ8ZNj6KKY=; b=lJPYgb7WqCXPcekwz0CGsk0TtWjD3R+uI5i5Kktz/REk3bcBD6GJdYMe0bqCASuJtS98hz0MU26FD1pUt09u66EvTlc1hyfHWDqTAq+W9IjD5IrSNUiSnOQZGGjvnAKHV2mueXsan1GRW0tmgYZQsXJROanQ6d/Wq838Nu1idOCvNT+mhzVoMOYU3YJgxlWw96JDTkbeCBlQYpm2aMNrAhrH5nGidREHK+o8bwvgx/gDfHsenjoBjspm9O5NqHnT/IQJGMtmNjhLMEVFM5YVNbtAzlrsU9ivQtuhi7etG7EF7KOEdUgpwCxa7ItIvrMAdC35pL3wmhqNXHciDJVPqw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=izhzs9cVpYjnbec1LisRX9RUKSCLf+BUttRkJYudzuNbwCxcGVbRytk98OfxvTNPveZW/CP45+HNSwB8QRJZB7jjS6dZaFj3DeH3K4V+hgZif/3JoMtLvV7mG4QxGpcTlheOC39iNq6RTZvfcWzM8XK9MiCSBw1kUNOqlGAjKGAcuaeopr5WfqjUDsQPzhlsihtFOHygoNatEC+ZV8/jiYjsKVeWul9NVPsLw0pTm2Yd9yuzeBOJqkBPuApGv7KlI4kfhByp6zuVxEJ77OBgpvGfAdG3P2I+6/fFjTAUNbjLYjV9dHS9BhT2QLV3erYjTH4Xha8PM7z/CY/sfDXgQw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 17 May 2022 14:46:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 17.05.2022 15:45, Roger Pau Monné wrote:
> On Tue, May 17, 2022 at 02:10:29PM +0200, Jan Beulich wrote:
>> On 09.05.2022 12:23, Roger Pau Monné wrote:
>>> On Fri, May 06, 2022 at 02:15:47PM +0200, Jan Beulich wrote:
>>>> On 03.05.2022 10:26, Roger Pau Monne wrote:
>>>>> --- a/xen/arch/x86/cpuid.c
>>>>> +++ b/xen/arch/x86/cpuid.c
>>>>> @@ -541,6 +541,9 @@ static void __init calculate_hvm_max_policy(void)
>>>>>           raw_cpuid_policy.basic.sep )
>>>>>          __set_bit(X86_FEATURE_SEP, hvm_featureset);
>>>>>  
>>>>> +    if ( boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
>>>>> +        __set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
>>>>> +
>>>>>      /*
>>>>>       * If Xen isn't virtualising MSR_SPEC_CTRL for HVM guests (functional
>>>>>       * availability, or admin choice), hide the feature.
>>>>
>>>> Especially with the setting of VIRT_SSBD below here (from patch 1) I
>>>> don't think this can go without comment. The more that the other
>>>> instance ...
>>>>
>>>>> @@ -597,6 +600,13 @@ static void __init calculate_hvm_def_policy(void)
>>>>>      guest_common_feature_adjustments(hvm_featureset);
>>>>>      guest_common_default_feature_adjustments(hvm_featureset);
>>>>>  
>>>>> +    /*
>>>>> +     * Only expose VIRT_SSBD if AMD_SSBD is not available, and thus
>>>>> +     * VIRT_SC_MSR_HVM is set.
>>>>> +     */
>>>>> +    if ( boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
>>>>> +        __set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
>>>>> +
>>>>>      sanitise_featureset(hvm_featureset);
>>>>>      cpuid_featureset_to_policy(hvm_featureset, p);
>>>>>      recalculate_xstate(p);
>>>>
>>>> ... here is about default exposure, so cannot really be extended to
>>>> the condition under which this is put in "max" (except that of course
>>>> "max" needs to include everything "def" has).
>>>
>>> Would you be OK with adding:
>>>
>>>     /*
>>>      * VIRT_SC_MSR_HVM ensures the selection of SSBD is context
>>>      * switched between the hypervisor and guest selected values for
>>>      * HVM when the platform doesn't expose AMD_SSBD support.
>>>      */
>>
>> I'm afraid this doesn't explain what I'm after. In
>> calculate_hvm_def_policy() the comment explains why / when the feature
>> is exposed by _default_. Taking into account patch 1 (where another
>> maximum exposure of the feature was introduced), I'd like the
>> comment in calculate_hvm_max_policy() to focus on the difference
>> between default and maximum exposure (which could be as simple as "if
>> exposed by default, also needs exposing in max, irrespective of the
>> further max exposure below(?)").
> 
> So something like:
> 
> /*
>  * When VIRT_SSBD is exposed in the default policy as a result of
>  * VIRT_SC_MSR_HVM being set  also needs exposing in the max policy.
>  */
> 
> Would address your concerns?

Yes (with - nit - the double blank dealt with, perhaps by inserting
"it" and maybe a comma).

Jan




 


Rackspace

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