From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from userp2130.oracle.com ([156.151.31.86]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1f8uNw-0001Hp-8I for speck@linutronix.de; Wed, 18 Apr 2018 23:13:02 +0200 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3ILBU9O023544 for ; Wed, 18 Apr 2018 21:12:46 GMT Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2hdrxnvnam-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 18 Apr 2018 21:12:46 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w3ILCjeJ005249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 18 Apr 2018 21:12:45 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w3ILCj4g032519 for ; Wed, 18 Apr 2018 21:12:45 GMT Date: Wed, 18 Apr 2018 17:12:40 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: GPZv4 Message-ID: <20180418211235.GA8545@localhost.localdomain> References: <67ef414c-f57c-0300-973b-f8898ee4d3b1@redhat.com> <20180418024816.GA6450@localhost.localdomain> <071ce2ea-c47d-9ae7-3e66-2e14ee32b97a@redhat.com> <1c1c86c5-664b-42a4-44bb-fd8853a55e41@redhat.com> <20180418145216.GB9939@localhost.localdomain> <560c94a1-41c4-f03f-d89f-9298b282b4eb@redhat.com> MIME-Version: 1.0 In-Reply-To: <560c94a1-41c4-f03f-d89f-9298b282b4eb@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Apr 18, 2018 at 11:02:35AM -0400, speck for Jon Masters wrote: > On 04/18/2018 10:52 AM, speck for Konrad Rzeszutek Wilk wrote: > > On Wed, Apr 18, 2018 at 10:07:44AM -0400, speck for Jon Masters wrote: > >> On 04/18/2018 10:04 AM, speck for Thomas Gleixner wrote: > >>> On Wed, 18 Apr 2018, speck for Jon Masters wrote: > >>>> On 04/18/2018 04:54 AM, speck for Thomas Gleixner wrote: > >>>>> On Tue, 17 Apr 2018, speck for Konrad Rzeszutek Wilk wrote: > >>>>>> 2). SBB vs MDD vs SBBD. > >>>>>> > >>>>>> MDD = Memory Disambiguation Disable > >>>>>> SBB = Speculative Store Bypass > >>>>>> SBBD = Speculative Store Bypass Disable > >>>>>> > >>>>>> Thomas likes 'MDD', Jon likes 'SBB', but he is also fine with 'SBBD'. > >>>>> > >>>>> I'm fine with SBBD as well. It's the same semantics as the other knobs as > >>>>> it controls the mitigation. > >>>> > >>>> Great. Might I recommend keeping what I sent to Konrad (both mdd and > >>>> ssbd recognized), but do whichever you like Konrad ;) > >>>> > >>>>> So can we for now just start with the minimal set of auto, off, on and then > >>>>> hash out the prctl or not question. The big hammer is the most important > >>>>> piece we need to have ready for merging when the embargo is lifted. > >>>> > >>>> I've sent the big hammer patches last night. Konrad's original set with > >>>> a few fixes, and just does "auto", "off", "on", and tested working ok. > >>> > >>> Can we please have proper mail submitted patches? These tarballs are a > >>> PITA. > >> > >> Leaving the ball with Konrad to review/post when he's happy. > > > > Sure thing. Will crank on them tonight/tomorrow morning. And tomorrow > > night or Friday folks can rip in them. > > > > Will post them as v2! > > Great. Paolo is pondering the KVM side of things some more - we just > synced up on a few concerns I've got around exposing SPEC_CTRL. Due to > how Intel did this for guests, of course a guest can be started with MD > set but then whack it because it's not aware of that bit. From a Linux Exactly. One of the patches takes care of that. It worked for me correctly, but I always appreciate more folks eye-balling it. > PoV this is why I suggested a todo (feel free to incorporate if you > like) that x86_spec_ctrl_base be initially set at boot with an rdmsr. > Then we'd at least preserve additional new bits that are added later. Right. And we can mask it. > > For other OSes, it might be we end up with a trapping solution for those > who want to be able to override a guest's view of MD if Intel can't be > persuaded to make MD lockable or something (as Paolo said, shadowing is > probably overkill/not possible at this point). But having an 'ignore these XYZ guest bitfields' would be good. Thank you for poking Intel on this. > > Jon. > > -- > Computer Architect | Sent from my Fedora powered laptop >