Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4911639imm; Tue, 26 Jun 2018 02:42:05 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKYPNqxQHTUgAMW0Ms2ewDRIO6eMGvpgog9VNkmEn5CsCW8s9v8lFpEUVmJNv6ejiARcRH9 X-Received: by 2002:a17:902:201:: with SMTP id 1-v6mr858238plc.310.1530006124985; Tue, 26 Jun 2018 02:42:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530006124; cv=none; d=google.com; s=arc-20160816; b=fx455gaELjXdfq14e3kG/h/1rtnC61Kn/fuiwcro003VPs/FBpKTqgC2iqlnn2wqxp klgz9gkF4rVVPwa9hMFFePZ5SErH+pjsDA4xaYp1PB+vqjUuJo9fk9Xh2UmHHf3NvdTJ gqKodHQpuZD26TD2Q7BSqfUUhqp60k4/g3HBD9rHVdhtYTEa/SuS/Yng/ynoAzFKEEF6 FS9CtDDrvf1IcoJExGnzIhqjZ97P2iwnGPv40NYrIKKYRljfjjMmnUowWcda1OBZrM7l 82mUFCVnlKyWGyc7/ntJPSQ6b4QDNft/4OKZmmj0eddQogTSH1QVAoEpn2xNSkfaAstx 44Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=BmlgmHfvEeD5nTzx5IWhXPJpqaIzdFGT/+s6bzyG3/8=; b=G4Es76rbEp9126C1/fYhf5cjCcbQig+R9MgX78/ZHOr+BZQB/I94s4vddzTXWnPvLC VUEBqdeLcAnpX3W1EIx7rBpTV0BttkBM9eqS4/xHN1XqvT/UrOAUUp0hIvHA4Jm2wjam PmE9yXs2lrRUNxtnsLtmaTs6g2dvXva+askbGe5C7dGZfbC5xuSLvjZYko5f34g+l5bY ZIrWMgyNPsbY8/Sj1DecEe4AJWqBOjIR0x9C9X3+weuIRCrSIMXbDCKl0U9BFYj+8/5m x9dGIRh6HlgSHjUuLVRXfD8IIy047CMoDbBMU947XIZB4YGuCwHPJ19YXuag3O2KnYaO +cPA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x66-v6si1241179pfb.97.2018.06.26.02.41.50; Tue, 26 Jun 2018 02:42:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933593AbeFZJlB (ORCPT + 99 others); Tue, 26 Jun 2018 05:41:01 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:49277 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932206AbeFZJlA (ORCPT ); Tue, 26 Jun 2018 05:41:00 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fXkSw-0005p3-GY; Tue, 26 Jun 2018 11:40:50 +0200 Date: Tue, 26 Jun 2018 11:40:50 +0200 (CEST) From: Thomas Gleixner To: Peter Zijlstra cc: Alan Cox , Fenghua Yu , Ingo Molnar , "H. Peter Anvin" , Ashok Raj , Dave Hansen , Rafael Wysocki , Tony Luck , Ravi V Shankar , Arjan van de Ven , linux-kernel , x86 Subject: Re: [RFC PATCH 06/16] x86/split_lock: Save #AC setting for split lock in firmware in boot time and restore the setting in reboot In-Reply-To: <20180626090521.GF2494@hirez.programming.kicks-ass.net> Message-ID: References: <1527435965-202085-1-git-send-email-fenghua.yu@intel.com> <1527435965-202085-7-git-send-email-fenghua.yu@intel.com> <20180621195823.GD13636@worktop.programming.kicks-ass.net> <1529680267.4364.50.camel@linux.intel.com> <20180626090521.GF2494@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 26 Jun 2018, Peter Zijlstra wrote: > On Fri, Jun 22, 2018 at 04:11:07PM +0100, Alan Cox wrote: > > On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote: > > > On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote: > > > > Firmware may contain split locked instructions. > > > > > > I think that's the wrong attitude. You should mandate in your BIOS > > > development guide that Firmware _MUST_NOT_ contain unaligned LOCK > > > prefixed instructions. > > > > > > > In the longer term I would agree entirely with that sentiment. > > But then how do we deal with SMIs ? The firmware people will at least > need to know about this, and the quick fix is to make the SMI handler > save/restore the MSR, but since they're aware and already changing their > code, they might as well fix the actual problem -- which is likely > trivial. > > So no, I don't buy it. Just fix the firmware instead of allowing them to > fester and grow layers of ducttape. > > Because even for SMM WRMSR is 100s of cycles, and why would they want to > make every single SMI more expensive. > > Also, as mentioned earlier, what are we going to do about SMIs in > general? They're a _far_ _FAR_ bigger problem for RT workloads than a > sporadic split atomic. Esp. with some vendors thinking they can run > bitcoin miners in SMI (or whatever else it is that is taking miliseconds > of compute time). > > Split atomics are an insignificant problem compared to the nightmare > trainwreck that is SMM. Aside of that, the split lock detection is only available for not yet released silicon. So there is absolutely _ZERO_ reason to force the kernel to deal with broken BIOSes. This would be a different story if the feature would break gazillion of shipped systems. So there is no 'In the longer term'. It's still enough time to fix the BIOS hackery _before_ any of this hits a production line. Ergo. This is not going to go anywhere near the x86 kernel code ever. We are not fostering completely avoidable engineering trainwrecks. To be honest, this part of the patch set should have never seen the light of LKML and we neither should have that discussion in the first place. Thanks, tglx