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

[Sean Christopherson]

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.