From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from userp2120.oracle.com ([156.151.31.85]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fIn1P-0003SU-KX for speck@linutronix.de; Wed, 16 May 2018 05:22:36 +0200 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4G3LUFd162021 for ; Wed, 16 May 2018 03:22:28 GMT Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2hx29w2upg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 16 May 2018 03:22:28 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4G3MRRF021015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 16 May 2018 03:22:27 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4G3MRLD017904 for ; Wed, 16 May 2018 03:22:27 GMT Date: Tue, 15 May 2018 23:22:26 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [patch 07/15] Hidden 7 Message-ID: <20180516032226.GG18660@char.us.oracle.com> References: <20180513140048.543641807@linutronix.de> <20180513140538.798644579@linutronix.de> MIME-Version: 1.0 In-Reply-To: <20180513140538.798644579@linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Sun, May 13, 2018 at 04:00:55PM +0200, speck for Thomas Gleixner wrote: > Subject: [patch 07/15] x86/bugs, KVM: Extend speculation control for VIRT_SPEC_CTRL > From: Thomas Gleixner > > AMD is proposing a VIRT_SPEC_CTRL MSR to handle the Speculative Store > Bypass Disable via MSR_AMD64_LS_CFG so that guests do not have to care > about the bit position of the SSBD bit and thus facilitate migration. Oh, that is news to me. Is there an MSR value they had in mind? > Also, the sibling coordination on Family 17H CPUs can only be done on > the host. > > Extend x86_spec_ctrl_set_guest() and x86_spec_ctrl_restore_host() with an > extra argument for the VIRT_SPEC_CTRL MSR. > > Hand in 0 from VMX and in SVM add a new virt_spec_ctrl member to the CPU > data structure which is going to be used in later patches for the actual > implementation. Why not expand it on VMX? That is couldn't this virtualized MSR be generic to do the appropiate mitigation on both AMD and Intel? After all this is a software emulated MSR - so why make VMX ignore it? (And yes I know the counter-argument - on Intel it should whack the SPEC_CTRL MSR instead of fiddling with this - but then why have an 'virtualized' MSR that is suppose to be generic!). ..snip.. > +++ b/arch/x86/kvm/svm.c > @@ -213,6 +213,12 @@ struct vcpu_svm { > } host; > > u64 spec_ctrl; > + /* > + * Contains guest-controlled bits of VIRT_SPEC_CTRL, which > + * will be translated into the appropriate bits to perform s/bits/bits on the host/ ? > + * speculative control. > + */ > + u64 virt_spec_ctrl; > > u32 *msrpm; >