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

Re: [PATCH v3 3/3] amd/msr: implement VIRT_SPEC_CTRL for HVM guests using legacy SSBD


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 22 Apr 2022 11:55: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=a04gQxjp43IJV6/yDVIkrX8c05kdMCFzPAj6huzj8to=; b=dCUZvGi5maHmHd6wTRdX4PcJ2xFLIsLkEmreG+C6qW7C6ckLY7nkYGslAd231s/s0g5PaNGUKPbIuRiTsgJ/CaJCh3BTACHo3ZG2LrMD+yIG9LqdjBzGxFd7hhietuY8C/HOYlqYE3e9SubjzPhVw7m8b7oEEz0VhlAZtTdssSY2PgBE9MRXQRwtsbcAcbDSPMHeKgaDA9cWhvbas111JrePRKTE6KT2lO7Rs6n2ymxZIAVbGSsUdZxBFSuf0jcrPo6pFamosiaHidk9Pm1tOM+15NptUeX08eLQH3tY9qTtPvreXhFrYshYc7GfqkIssz2Y/g61qz9xDUJkjkB+yw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cmwjwAyTivmZWVxdjV12zNpEyuCbUBE6RqvWijMTOrveP6D3EoPGlvgCa/44EtDy3VPjSmySFUh2xQqw92mo8EgPtxY+m3W3yyHawk1QKcXqBmToNfgY5bbycntaFqogXuI0vzACL72Yq4eS7GcHkebRH8zsAX99CnoQh3g73B8mp9/U7Xfgz7iqKm08O9rNioGc2MKqKxwTsZBzyyJuC6cAXutXcWCm32hOu/DVMsi+ko6lROYWvGIR7LI7IhRqSYKCNE8xP/ckzcq2pk5un/IgEcn2luC54YEyxAbnZCqC+CcqG3WADInx6R3fjWWQaNDsbfvgwr1wmfkeKSuj6Q==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 22 Apr 2022 09:56:14 +0000
  • Ironport-data: A9a23:4y48L6yt8t7osKnWOUJ6t+dDxyrEfRIJ4+MujC+fZmUNrF6WrkUDm DRMDTyFOq6NZTakfNkiPd6xoRhQu5OGydUyTVBsrSAxQypGp/SeCIXCJC8cHc8zwu4v7q5Dx 59DAjUVBJlsFhcwnj/0bv656yMUOZigHtIQMsadUsxKbVIiGX9JZS5LwbZj2NY024LhWmthh PupyyHhEA79s9JLGjp8B5Kr8HuDa9yr5Vv0FnRnDRx6lAe2e0s9VfrzFonoR5fMeaFGH/bSe gr25OrRElU1XfsaIojNfr7TKiXmS1NJVOSEoiI+t6OK2nCuqsGuu0qS2TV1hUp/0l20c95NJ NplurebYkBuMZHwlekcdEdoLHtyE6Qa0eqSSZS/mZT7I0zuVVLJmq8rJmdmeIoS96BwHH1E8 uEeJHYVdBefiumqwbW9DO5xmsAkK8qtN4Qa0p1i5WiBUbB6HtaeHuOTuocwMDQY36iiGd7EY MUUc3x3ZQnoaBxTIFYHTpk5mY9Eg1GgK2UJ8QLL+cLb5UD80iot3IWzGub1e4e2fvlMwwW3t 3LZqjGR7hYycYb3JSC+2nCmi/LLnCj7cJkPD7D+/flv6HWMwkQDBRtQUkG0ydGph0j7V99BJ kg8/is1sbN05EGtVsP6XRCzvDiDpBF0ZjZLO+gz6QXIwKyE5Q+cXzIAVmQYN4Rgs9IqTzs30 FPPh8nuGTFkrLySTzSa66uQqjSxfyMSKAfueBM5cOfM2PG7yKlbs/4FZowL/HKd5jEtJQzN/ g==
  • Ironport-hdrordr: A9a23:VLDouKsq3tUTkBpJKrI/z+/s7skCJ4Aji2hC6mlwRA09TyXGra 6TdaUguiMc1gx8ZJh5o6H9BEGBKUmskaKdkrNhQotKPTOW9ldASbsC0WKM+UyZJ8STzJ8+6U 4kSdkCNDSSNyk6sS+Z2njCLz9I+rDum8rE5Za8854ud3ARV0gK1XYfNu/vKDwOeOAwP+teKH Pz3LsjmxOQPVAsKuirDHgMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlil9yZbdwkK7aYp8G DDnQC8zL6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4sow3TX+0SVjbZaKvm/VQMO0aaSAZER4Z /xSiIbToFOArXqDziISFXWqlHdOX0VmgHfIBej8AreSIrCNWkH4oN69PFkWwHE5UQtpsxx3Z RCwn+QvZtSARTcqj7w/cLJURZdlkfcmwtTrccDy3NYSocQc7lXsMgW+15UCo4JGGbg5JkgC/ QGNrCQ2B/4SyLsU5n1hBgl/DWXZAV4Iv5GeDl1huWFlzxN2HxpxUoRw8IS2n8G6ZImUpFBo+ DJKL5hmr1CRtIfKfsVPpZPfeKnTmjWBR7cOmObJlrqUKkBJnLWspbypLE4/vujdpAExIY73J 7BTFRbv2gvfF+GM7zD4LRbthTWBGmtVzXkzc9To5B/p73nXbLudTaOTVg/+vHQ68n3wverEs pbFKgmdsMLd1Gea7qh9zeOL6VvFQ==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Apr 21, 2022 at 05:27:18PM +0200, Jan Beulich wrote:
> On 21.04.2022 17:21, Roger Pau Monné wrote:
> > On Thu, Apr 21, 2022 at 11:50:16AM +0200, Jan Beulich wrote:
> >> On 31.03.2022 11:27, Roger Pau Monne wrote:
> >>> Expose VIRT_SSBD to guests if the hardware supports setting SSBD in
> >>> the LS_CFG MSR (a.k.a. non-architectural way). Different AMD CPU
> >>> families use different bits in LS_CFG, so exposing VIRT_SPEC_CTRL.SSBD
> >>> allows for an unified way of exposing SSBD support to guests on AMD
> >>> hardware that's compatible migration wise, regardless of what
> >>> underlying mechanism is used to set SSBD.
> >>>
> >>> Note that on AMD Family 17h (Zen 1) the value of SSBD in LS_CFG is
> >>> shared between threads on the same core, so there's extra logic in
> >>> order to synchronize the value and have SSBD set as long as one of the
> >>> threads in the core requires it to be set. Such logic also requires
> >>> extra storage for each thread state, which is allocated at
> >>> initialization time.
> >>
> >> So where exactly is the boundary? If I'm not mistaken Zen2 is also
> >> Fam17 (and only Zen3 is Fam19), yet here and elsewhere you look to
> >> take Zen1 == Fam17.
> > 
> > Right, but Zen2 already has AMD_SSBD (ie: SPEC_CTRL), so it's not
> > using this logic.
> > 
> > The AMD whitepaper is more clear about this: any Fam17h processor that
> > is using the non-architectural MSRs to set SSBD and has more than 1
> > logical processor for each logical core must synchronize the setting
> > of SSBD.
> > 
> > I think just dropping the mention of Zen 1 in the commit message
> > should remove your concerns?
> 
> Or keep it, but qualify it by saying that Zen2 isn't expected to take
> this path because of having SSBD. But iirc SSBD was introduced to
> Zen2 only by a ucode update, so such a description should not be wrong
> wrt such not-up-to-date systems.

FTAOD I've worded this as:

"Note that on AMD Family 17h and Hygon Family 18h processors the value
of SSBD in LS_CFG is shared between threads on the same core, so
there's extra logic in order to synchronize the value and have SSBD
set as long as one of the threads in the core requires it to be set.
Such logic also requires extra storage for each thread state, which is
allocated at initialization time."

Which I think is correct in all cases.  Iff Zen2 was to resort to
using the non-architectural way of setting SSBD (if that's even
possible) it should synchronize it between threads according to my
read of the AMD whitepaper.

I've also added handling for Hygon Fam18h, seeing as those also make
use of the non-architectural way of setting SSBD.

Thanks, Roger.



 


Rackspace

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