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 ; 29 Jun 2018 21:49:16 -0000 Received: from mga02.intel.com ([134.134.136.20]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fZ1GU-00005e-6Y for speck@linutronix.de; Fri, 29 Jun 2018 23:49:15 +0200 Date: Fri, 29 Jun 2018 14:49:11 -0700 From: Andi Kleen Subject: [MODERATED] Re: [PATCH 1/1 v2] Linux patch #1 Message-ID: <20180629214911.GA17013@tassilo.jf.intel.com> References: <20180629164807.lxbjex6m64xyfhgc@treble> <20180629195427.sj2jl4oqgavdozhf@treble> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: > Agreed; thinking about this a little bit more from admin POV, I think we > should just go with > > (1) l1tf=full > That would currently mean PTEINV + nosmt=force, and later once the > KVM/Xen bits land in, they will make use of it as well (KVM will start > doing the flushes (*), Xen doing the PTE sanitization or their variant > of gang scheduling or whatnot) That means everyone who doesn't use KVM or uses KVM in a way that is safe wastes 30%+ of performance completely unnecessarily. I don't think this is a good idea. Everyone who disables SMT should make a conscious decision on this. L1TF is complex and "turn off your brain, just use big hammer" is not a suitable strategy for it. KVM already prints warnings when SMT is on, this can be perhaps made more clear. The decision tree for starting KVM with SMT on is roughly: - If you trust your guests do nothing - If your KVM is in a cpuset or affinity that has its own set of cores do nothing (we usually assume interrupts leaking are not a problem) - Then first try to bind the KVM to a subset of cores and only turn off SMT for those - If that all fails turn off SMT globally. This should be an explicit option, not lumped in with something else. -Andi