Re: [patch v2 1/2] x86,module: Detect VMX modules and disable Split-Lock-Detect

From: Thomas Gleixner <tglx@linutronix.de>
To: Sean Christopherson <sean.j.christopherson@intel.com>,
	Peter Zijlstra <peterz@infradead.org>
Cc: Xiaoyao Li <xiaoyao.li@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	x86@kernel.org, "Kenneth R. Crudup" <kenny@panix.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Jessica Yu <jeyu@kernel.org>,
	Fenghua Yu <fenghua.yu@intel.com>, Nadav Amit <namit@vmware.com>,
	Thomas Hellstrom <thellstrom@vmware.com>,
	Tony Luck <tony.luck@intel.com>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [patch v2 1/2] x86,module: Detect VMX modules and disable Split-Lock-Detect
Date: Thu, 02 Apr 2020 23:04:05 +0200	[thread overview]
Message-ID: <87blo9mwfu.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200402202321.GL13879@linux.intel.com>

Sean Christopherson <sean.j.christopherson@intel.com> writes:
> On Thu, Apr 02, 2020 at 08:51:48PM +0200, Peter Zijlstra wrote:
>> On Thu, Apr 02, 2020 at 10:51:28AM -0700, Sean Christopherson wrote:
>> > On Thu, Apr 02, 2020 at 07:34:35PM +0200, Thomas Gleixner wrote:
>> > > Aside of that I'm still against the attempt of proliferating crap,
>> > > i.e. disabling it because the host is triggering it and then exposing it
>> > > to guests. The above does not change my mind in any way. This proposal
>> > > is still wrong.
>> > 
>> > Eh, I still think the "off in host, on in guest" is a legit scenario for
>> > debug/development/testing, but I agree that the added complexity doesn't
>> > justify the minimal benefits versus sld_warn.
>> 
>> Off in host on in guest seems utterly insane to me. Why do you care
>> about that?
>
> For development/debug/testing.  Ignoring the core-scope stupidity of split
> lock, the _functional_ behavior of the host kernel and guest kernel are
> completely separate.  The host can generate split locks all it wants, but
> other than performance, its bad behavior has no impact on the guest.
>
> For example, all of the debug that was done to eliminate split locks in the
> kernel could have been done in a KVM guest, even though the host kernel
> would not have yet been split-lock free.
>
> It's somewhat of a moot point now that the kernel is split-lock free.  But,
> if I encountered a split lock panic on my system, the first thing I would
> do (after rebooting) would be to fire up a VM to try and reproduce and
> debug the issue.
>
> Oftentimes it's significantly easier to "enable" a feature in KVM, i.e.
> expose a feature to the guest, than it is to actually enable it in the
> kernel.  Enabling KVM first doesn't work if there are hard dependencies on
> kernel enabling, e.g. most things that have an XSAVE component, but for a
> lot of features it's a viable strategy to enable KVM first, and then do all
> testing and debug inside a KVM guest.

I can see that aspect, but there were pretty clear messages in one of
the other threads:

 "It's not about whether or not host is clean. It's for the cases that
  users just don't want it enabled on host, to not break the
  applications or drivers that do have split lock issue."

 "My thought is for CSPs that they might not turn on SLD on their
  product environment. Any split lock in kernel or drivers may break
  their service for tenants."

which I back then called out as proliferating crap and ensuring that
this stuff never gets fixed.

I still call it out as exactly that and you know as well as I do that
this is the reality.

For people like you who actually want to debug stuff in a guest, the
extra 10 lines of hack on top of the other 1000 lines of hacks you
already have are not really something which justifies to give hardware
and OS/application vendors the easy way out to avoid fixing their broken
crap.

Thanks,

        tglx