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

Re: [PATCH 4/4] amd/virt_ssbd: add to max HVM policy when SSB_NO is available


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 13 Oct 2022 16:43:15 +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=Hq+G0iSYkV+qrVAVCsOyKXcfo+N7nJBx4VPKuCQI7D4=; b=lNpPcqxbGvNEmSzc+1p5QM0wAjXM9VejGbzpVgugpEDoqtgAQkcXbYax8lU7WpHlp6NkwKJI546ZWk/BKw4rsMq5Y1YqSdB3lOehN5E5t/+j/p3pRkJLLO5g+5bYbQQ+MeeMmEI1WCaeN6hST9YrI/9R66IZUXyaSJUnpc11n1PHsuNSSaL9d9rtMkh0gDg4LpiEBu0xNJGA6YIUv3B+LD6P8s6rZsiUp0b9i2kbywxOJvXB7bdYvcmdwB2L0f4bRmPFDukhB1MWDaJCa1Mh+a3cJ6UfUUdNNOjpJ0Fs/9Mg5vobUhf0+f+OM5pNWmpr2wjxwqn4N1Innp/QJeTjrg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B++1GW0yvL1nbw0v4lJcmRBdpjDdeLAzgRe+w3kN0r+S4qieg+SFybG/htdi8qHi3kAFQ3JTuquJKuNCo8qBvWGS7dQizBQBteiK12DJWSaDg169KfFLqS6Mc+JVoTCpn0F0oArKMo8qKkBZOpa48UtaJzoxiJaZc0ZInxo7bo+/bteoV8Bcj3YTNVamGJgx7Yzx+4ElIsA0fYsItCCNockp1SrLPJiT4IEQiJ+AX/9bS7k2A070t8XFqM5MOGbDgaPQNOSx8kK5cSnD0mSpoxnVlwEC+4F0D797FVN3NX2fkBIq9HybWwOgM7WGzOqHQ8W6iPp2k67xobIJmxcOKg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Henry.Wang@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 13 Oct 2022 14:43:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 13.10.2022 16:06, Roger Pau Monné wrote:
> On Wed, Oct 12, 2022 at 10:36:57AM +0200, Jan Beulich wrote:
>> On 11.10.2022 18:02, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/cpu/amd.c
>>> +++ b/xen/arch/x86/cpu/amd.c
>>> @@ -814,7 +814,9 @@ void amd_set_ssbd(bool enable)
>>>             wrmsr(MSR_VIRT_SPEC_CTRL, enable ? SPEC_CTRL_SSBD : 0, 0);
>>>     else if ( amd_legacy_ssbd )
>>>             core_set_legacy_ssbd(enable);
>>> -   else
>>> +   else if ( cpu_has_ssb_no ) {
>>
>> Nit: While already an issue in patch 1, it is actually the combination
>> of inner blanks and brace placement which made me spot the style issue
>> here.
> 
> Oh, indeed, extra spaces.
> 
>>> +           /* Nothing to do. */
>>
>> How is the late placement here in line with ...
>>
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -558,11 +558,16 @@ static void __init calculate_hvm_max_policy(void)
>>>          __clear_bit(X86_FEATURE_IBRSB, hvm_featureset);
>>>          __clear_bit(X86_FEATURE_IBRS, hvm_featureset);
>>>      }
>>> -    else if ( boot_cpu_has(X86_FEATURE_AMD_SSBD) )
>>> +    else if ( boot_cpu_has(X86_FEATURE_AMD_SSBD) ||
>>> +              boot_cpu_has(X86_FEATURE_SSB_NO) )
>>>          /*
>>>           * If SPEC_CTRL.SSBD is available VIRT_SPEC_CTRL.SSBD can be 
>>> exposed
>>>           * and implemented using the former. Expose in the max policy only 
>>> as
>>>           * the preference is for guests to use SPEC_CTRL.SSBD if available.
>>> +         *
>>> +         * Allow VIRT_SSBD in the max policy if SSB_NO is exposed for 
>>> migration
>>> +         * compatibility reasons.  If SSB_NO is present setting
>>> +         * VIRT_SPEC_CTRL.SSBD is a no-op.
>>>           */
>>>          __set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
>>
>> ... this comment addition talking about "no-op"?
> 
> We need the empty `else if ...` body in order to avoid hitting the
> ASSERT, but a guest setting VIRT_SPEC_CTRl.SSBD on a system that has
> SSB_NO will not result in any setting being propagated to the
> hardware.  I can make that clearer.

I guess my question was more towards: Shouldn't that check in
amd_set_ssbd() move ahead?

As an aside I notice you use cpu_has_ssb_no there but not here. I
might guess this is because of the adjacent existing
boot_cpu_has(), but it still strikes me as a little odd (as in:
undue open-coding).

Jan



 


Rackspace

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