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 03:45:32 -0000 Received: from mga05.intel.com ([192.55.52.43]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fc0df-0001jd-5L for speck@linutronix.de; Sun, 08 Jul 2018 05:45:31 +0200 Date: Sat, 7 Jul 2018 20:45:11 -0700 From: Andi Kleen Subject: [MODERATED] Re: [PATCH 1/1] SMTDOCv2 0 Message-ID: <20180708034511.GL25550@tassilo.jf.intel.com> References: <20180706222456.35040-1-andi@firstfloor.org> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Sat, Jul 07, 2018 at 11:39:02AM +0200, speck for Thomas Gleixner wrote: > On Fri, 6 Jul 2018, speck for Andi Kleen wrote: > > --- /dev/null > > +++ b/Documentation/virtual/kvm/l1tf-mitigation.txt > > I seem to remember that I asked for RST format. Aside of that we really I probably lost that somewhere in your flood of ad hominems. > > @@ -0,0 +1,69 @@ > > +L1TF mitigation strategies in KVM > > +On some Intel CPUs a side channel attack may make it possible to read > > 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. > > > +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. > > 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. > > > + > > +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. -Andi