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

Re: [PATCH for-4.17 3/4] amd/ssbd: remove hypervisor SSBD selection


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 13 Oct 2022 16:20:45 +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=veQFpq4mgKJoYEVkuIX/6zOa2CK07IW2mMT67BUJpiU=; b=RbIsA2t1DXagkzvwCx1VkSCpiVIRoIfHja+FFzJ7HNyqm1/ZXbhoPp4PLlgg5LK4duGx0s4qUzoWK8SXaqqfycLRRLTu4/XyjJksmyFAtl33D1RD9ergrB589hggLBJgQ+8uxISpHmRzZt841Xxiw81wrFi5YdykGJBMAm75X7o9meMqC90MHVPk/uTH/AHLA5s2dTnqsxmggtClmft45S8kxSAq1cFASXIm58WPoKlUy+tjUYYRhj89nm+1Y+jNKuoQTOwltQgm/O5tLK1urN6PyCesgwLNu60DSdLzHGt+Zi/PacJ1biqCgSmLbKoaz+hqw59ZqBQQxAUHR+vm6A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m8WoEyX/Q1aSbfVa4rkAAveiprSAoTaOxAsOVCgOSKCZfpl1K4mgp4lCKXNg30SvVuXr95SqWIhD3A0wVn59swyQO9T/il9LaJ/l5y5G4gzNdIHmZ+EE452BLsVRfKbxTo9kTzAUzNTnrgtJLlMtJuuf2IkDWDETNlC3jf6jMPbjoWfPKgik+de7VnR5L4fDenoQSI8TwsQDUDp3jUyZVvK0BVkYcwKeQ87V6ngMojI2ByLvWzjg6/3EEPye59svfkA4QZYnQ4sgldm22Rk+p4Co0jBCGXI2hSlca4mjJy9lK645fpyBEyPJkOo9Z4k37zERrWtEmhqujmO/5lS1Yg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Henry.Wang@xxxxxxx, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 13 Oct 2022 14:20:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 13.10.2022 15:50, Roger Pau Monné wrote:
> On Wed, Oct 12, 2022 at 10:30:45AM +0200, Jan Beulich wrote:
>> On 11.10.2022 18:02, Roger Pau Monne wrote:
>>> @@ -2365,12 +2365,6 @@ On hardware supporting STIBP (Single Thread Indirect 
>>> Branch Predictors), the
>>>  By default, Xen will use STIBP when IBRS is in use (IBRS implies STIBP), 
>>> and
>>>  when hardware hints recommend using it as a blanket setting.
>>>  
>>> -On hardware supporting SSBD (Speculative Store Bypass Disable), the `ssbd=`
>>> -option can be used to force or prevent Xen using the feature itself.
>>
>> Why would we want to take away this level of control? Shouldn't we turn this
>> on while in Xen if so requested? Which would then either mean enabling it on
>> VMEXIT if a guest has it off, or running with it turned on using the OR of
>> guest and host settings.
> 
> Right, but then we need to context switch the value on vm{entry,exit}
> which is problematic.  I could move the context switch code code out
> of the GIF=0 region, and assume that NMIs executing with the guest
> selection of SSBD are OK.
> 
> Alternatively setting ssbd= on the command line could be taken as a
> value to enforce for the whole system and prevent guest attempts to
> change it, not exposing VIRT_SSBD, AMD_SSBD or SSBD (haven't
> looked at whether not exposing the SSBD CPUID related to
> SPEC_CTRL.SSBD will have impact on other features).

That would be my preference (albeit I'm uncertain about the "not exposing"
part, as we don't want to misguide guests into thinking they're unsafe or
can't guarantee safety when requested by user mode code), but ...

> I was under the impression that the command line ssbd option was added
> to cope with Xen not exposing the feature to guests. Now that the
> feature is exposed guests should be free to make use of it, and hence
> there's no need to force a value for Xen.

... me not having had this understanding may have been wrong on my part.
Andrew - any chance you could clarify (original) intentions here?

Jan



 


Rackspace

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