From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from aserp2120.oracle.com ([141.146.126.78]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fEe5c-00081C-AR for speck@linutronix.de; Fri, 04 May 2018 19:01:49 +0200 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w44H1GSW030975 for ; Fri, 4 May 2018 17:01:41 GMT Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2hmgxg75h2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 04 May 2018 17:01:41 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w44H1eXX002069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 4 May 2018 17:01:40 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w44H1etv027731 for ; Fri, 4 May 2018 17:01:40 GMT Date: Fri, 4 May 2018 13:01:38 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [PATCH 4/5] SSB extra 5 Message-ID: <20180504170138.GA24767@char.us.oracle.com> References: =?utf-8?q?=3C1eb961?= =?utf-8?q?8baa7b4d021ee5255cf138a6ebc3c3984a=2E1525383411=2Egit=2Edave=2E?= =?utf-8?q?hansen=40intel=2Ecom=3E?= MIME-Version: 1.0 In-Reply-To: =?utf-8?q?=3C1eb9618baa7b4d021ee5255cf138a6ebc3c3984a=2E15253?= =?utf-8?q?83411=2Egit=2Edave=2Ehansen=40intel=2Ecom=3E?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, May 03, 2018 at 03:29:47PM -0700, speck for Dave Hansen wrote: > From: Dave Hansen > Subject: x86, bugs: centralize SPEC_CTRL MSR mask generation > > From: Dave Hansen > > The KVM code manipualtes the SPEC_CTRL MSR when it enters and exits > the guest. It overwrites the "kernel" value when it enters the guest > and restores the "kernel" value after leaving the guest. > > Both code paths take into account the "base" (x86_spec_ctrl_base) > value and the per-task TIF_RDS flag (on Intel). They then see if the > new state differs from the existing state and avoid the MSR write if > no change is made. > > But, these two paths could be a bit more unified. Introduce a new > function: x86_calculate_kernel_spec_ctrl() which will figure out the > "kernel" value to contrast it with the "guest" value. We also > rename the arguments to the set/restore functions to make it clear > that while the arguments are both "guest" state, they really mean > different things to the two functions. > > This will make the next step easier when we have more state to > consult in doing the x86_calculate_kernel_spec_ctrl() calculatione > > Signed-off-by: Dave Hansen Reviewed-by: Konrad Rzeszutek Wilk