Re: [RFC PATCH v1] x86/split_lock: Provide KVM helper to log guest bus lock exits

[Sean Christopherson <seanjc@google.com>]

On Wed, Apr 08, 2026, Manali Shukla wrote:
> On 3/31/2026 11:04 PM, Sean Christopherson wrote:
> > On Tue, Mar 24, 2026, Manali Shukla wrote:
> >> The intent is purely observational — give hypervisor owners
> >> visibility into which guest is generating bus locks so they can act
> >> accordingly. No policy enforcement is done in the kernel. Suggestions
> >> on the approach are welcome.
> > 
> > This makes no sense.  KVM is exiting to userspace, the hypervisor owner doesn't
> > need to grep dmesg to understand *exactly* what vCPU is generating bus locks.
> 
> I agree that the VMM receives KVM_EXIT_X86_BUS_LOCK and knows which vCPU
> caused it, and I am fine with that approach. However, this request came
> from a customer who wanted to know which guest is causing bus locks at
> which RIP in dmesg,

Ratelimited printks are not features.  

> similar to how split lock detection on Intel does it. 

Split lock #AC is something entirely different.  In that case, KVM intercepts an
#AC and does NOT exit to userspace.  The printk in that case is warranted because
the host kernel is disabling a mitigation for the thread to allow forward progress.

The analogous Intel feature is BUS_LOCK_DETECTION, and KVM's implementation
most definitely doesn't log anything to dmesg.  That was very intentional, as
the primary goal of the implementation was to give userspace full control over
how to react to misbehaving guests.

Sorry, but this gets a very firm NAK from me.