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

[Sean Christopherson <sean.j.christopherson@intel.com>]

On Thu, Apr 02, 2020 at 11:04:05PM +0200, Thomas Gleixner wrote:
> 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.

Or more likely, gets fixed, just not in upstream :-)

> 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.

Ya, I see where you're coming from.  As above, I agree that having a "KVM
only" mode does more harm than good.