[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: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 14 Oct 2022 10:11:54 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=NqbzFO+otW8dxCElDI1uhSFmo9Hh56qrw56hNcVnSw8=; b=XkWRnfqVyJOboqlRsmkSqUm6nR9l6ALpZqx6V9UWjumS2LWQcuuYucJDzsxUf3g0Q0QaNGrlUqG3VEsnwan4+xNP5ST0YmwpApiGUJv5GiqNd07S4uTHXjz/NFDJ6fzU0eBQQO84aDUs40+hVR/Fdx8a0aEAbSYu/MP+RCNk0VvC0JpL8z50oSPYq7fKcSpKogg+YD2UBl2TFi31svFr4eUD8TcFAIam1or6apeBZDelwhLpkCaMxyAVdjPXYojetwof7cNXxN8TCMhAVIARoBLWB8EIIfIYbNaLtp64l5EBFrbiyV1LUEwVz8LtnaeY2xVW/eu7fdcBR2uorFH1RQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VRbcfoioVDPhlfFkFi8/DO76m4kVQOp3qnsPIT5dtLl669BPyiOksCD7C8NfqwtLsSms4CxVVK74R6z1Yx9B55IjxGton9j15ZdSlckD8EOFhRzk7Tp95F5Hhq2Ll14pn9D2b9TUZ4gogc23LuhnN+rZVQsYmeFgC5durhj65WLvmKapczp6JgjJreaJC4QvIB9hLtbgf6M/Z/R1eY6FEqFQ1XfRr/u7ayLJ/msewDE0NyDuZqcGz0POEUbPjiCcUAdRD9RTiWaWQDyzlL0h5dzcJlYPAV1XSe8Mhg/ndsuZXA5Ejxu/bLKYxgaQ4qYQKvwa02thq2bwh1MkkUfx7Q==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Henry.Wang@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 14 Oct 2022 08:12:09 +0000
  • Ironport-data: A9a23:iszwiK+4AIXYgDgEzFXZDrUDt3+TJUtcMsCJ2f8bNWPcYEJGY0x3n WNNXW6HM/aJYGT0f413aNnlp0wGupeAnYQyQVA+qS88E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjUAOC6UIYoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE/ Nj/uKUzAnf8s9JPGj9Suv/rRC9H5qyo4mpA5wdmPpingXeF/5UrJMNHTU2OByOQrrl8RoaSW +vFxbelyWLVlz9F5gSNy+uTnuUiG9Y+DCDW4pZkc/HKbitq/0Te5p0TJvsEAXq7vh3S9zxHJ HehgrTrIeshFvWkdO3wyHC0GQkmVUFN0OevzXRSLaV/ZqAJGpfh66wGMa04AWEX0ulVA0UW6 PknESBTTiuahOapy7TrEeY506zPLOGzVG8ekldJ6GmFSNMZG9XESaiM4sJE1jAtgMwIBezZe 8cSdTtoalLHfgFLPVAUTpk5mY9EhFGmK2Ee9A3T+vFxujaDpOBy+OGF3N79YNuFSN8Thk+Fj mnH4374ElcRM9n3JT+toij327+XzXqTtIQ6CbiC6udWrE+vmGESIyEcUmGauqGjhRvrMz5YA wlOksY0loAw/kG2Stj2XzWjvWWJ+BUbXrJ4M+A88hDL9aPS7C6QHG1CRTlEAPQ5sOcmSDps0 UWG9/v5CDoqvLCLRHa18raPsSj0KSUTNXUFZyIPUU0C+daLnW0ophfGT9ImFbHviNTwQW302 2rT8nh4gKgPh8kW0an95UrAnz+nupnOSEgy+xnTWWWmqAh+YeZJerCV1LQS1t4YRK7xc7VLl CNsdxS2hAzWMaywqQ==
  • Ironport-hdrordr: A9a23:k+A/HKA08qn8YjPlHelx55DYdb4zR+YMi2TDj3oBLiC8cqSj+P xG785rsyMc6QxhIk3I9urwW5VoLUmwyXcx2/h0AV7AZniahILLFvAB0WKK+VSJcEfDH6xmpM JdmsNFZuEYeGIbsS+M2miF+rgbrOVvu5rY/Ns2h00dNT1CeuVq9AF8ChqeVkltSglKbKBJb6 ah2g==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Oct 13, 2022 at 04:43:15PM +0200, Jan Beulich wrote:
> 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?

Right, I assumed that cpu_has_ssb_no would be exclusive with any other
SSBD mechanism, but that doesn't need to be true.

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

Indeed, the whole function uses boot_cpu_has() so it seemed clearer to
also use it for SSB_NO.

Thanks, Roger.



 


Rackspace

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