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;
Date:   Tue, 26 Jun 2018 11:05:21 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Alan Cox <alan@linux.intel.com>
Cc:     Fenghua Yu <fenghua.yu@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@elte.hu>,
        "H. Peter Anvin" <hpa@linux.intel.com>,
        Ashok Raj <ashok.raj@intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Rafael Wysocki <rafael.j.wysocki@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Ravi V Shankar <ravi.v.shankar@intel.com>,
        Arjan van de Ven <arjan@infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
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
Message-ID: <20180626090521.GF2494@hirez.programming.kicks-ass.net>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1529680267.4364.50.camel@linux.intel.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.