From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 08 Jul 2018 10:20:00 -0000 Received: from p4fea482e.dip0.t-ipconnect.de ([79.234.72.46] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fc6nP-0004Mq-DU for speck@linutronix.de; Sun, 08 Jul 2018 12:19:59 +0200 Date: Sun, 8 Jul 2018 12:19:59 +0200 (CEST) From: Thomas Gleixner Subject: Re: [PATCH 1/1] SMTDOCv2 0 In-Reply-To: <20180708034511.GL25550@tassilo.jf.intel.com> Message-ID: References: <20180706222456.35040-1-andi@firstfloor.org> <20180708034511.GL25550@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Sat, 7 Jul 2018, speck for Andi Kleen wrote: > On Sat, Jul 07, 2018 at 11:39:02AM +0200, speck for Thomas Gleixner wrote: > > On some? L1TF affects every fricking Intel CPU with EPT except a few ATOMs. > > Think what will the state be when someone reads this in two years. It's not rocket science to spell it out in a way which is still valid in two years. > > > +arbitrary data in the L1D cache of the CPU core in the guest, potentially allowing > > > +to read data from outside the VM. > > > > This really wants to be explained so that the admin who is supposed to read > > that understands the mechanims at least at the high level. That > > 'may/potentially' weasel wording is not at all helpful to make decisions > > about the mitigations. > > There will be an Intel white paper with details, we can point to that later. > I don't think going into micro architectural details here will > help any admin. It's not about micro architectural details, but there needs to be some high level explanation so the administrator can make a judgement about the different mitigation methods. > > Fails? How should someone who is not familiar with the deep details of that > > decided that the above fails? > > It's a list of actions all with preconditions. For each it is clear > if you can or cannot do the action. Oh well.. > > > +SMT improves performance so it should be only disabled when absolutely > > > > SMT improves performance depending on the workload. There are workloads > > which are negatively impacted by SMT. > > > > That said, this all wants to be properly structured and explained in > > detail. A hastily cobbled together string of syllables does not make a > > document which is intended to provide guidance to people who do not have a > > deep technical insight into this. > > We can perhaps expand some things slightly. > > But I doubt any admin is interested in reading a novel on this here. I > certainly wouldn't be. There will be plenty of other material elsewhere for > people who want all the gory details. Nobody asks you to write a novel. But a consice documentation is surely due. Aside of that it does not matter how much other material will be available. This is about documentation the kernel provides and I consider it bad practice to throw a few bones into a text file just to claim that we have documentation. You might be content with that scrap paper, but most people prefer and appreciate proper written documentation. Thanks, tglx