Re: [PATCH v4 0/5] KVM: SVM: Add Bus Lock Detect support and refactor LBRV

[Sean Christopherson <seanjc@google.com>]

On Fri, Sep 25, 2026, Sean Christopherson wrote:
> On Tue, Jul 21, 2026, Shivansh Dhiman wrote:
> > Shivansh Dhiman (5):
> >   KVM: SVM: Refactor svm_update_lbrv()
> >   KVM: nSVM: Disable LBRV in nested control cache when unsupported
> >   KVM: nSVM: Sanitize nested DR6 using kvm_dr6_fixed()
> >   KVM: SVM: Turn DEBUGCTL_RESERVED_BITS into a helper
> >   KVM: SVM: Add Bus Lock Detect support
> 
> I'll send a v5 as I have variety of changes (I already responded to each patch),
> and I'm not in the mood to deal with another version as I'm quite grumpy that no
> one bothered to follow up on Sashiko's bug report, or to write tests.
> 
> I'll also post a KUT testcase, which I created to verify the bug Sashiko pointed
> out as well as the fix. 

You know what I *love* doing on a Friday afternoon?  Debugging ucode bugs because
apparently hardware engineers are also allergic to testing.  Or maybe the APM just
sucks more than usual.   But the behavior fundamentally breaks virtualization, so
IMO it's a hardware/ucode bug.

On Turin (the only AMD hardware with Bus Lock Detect I've tested), hardware/ucode
forces DR6.BLD=1 if DEBUGCTL.BLCKDB=0, even on software writes and even on loads
of DR6 via VMRUN (this last bit is what really throws a wrench in virtualization).

Software can still read DR6.BLD=0 if DEBUGCTL.BLCKDB=0, but if anything touches
DR6, DR6.BLD gets clobbered back to '1'.  E.g. if the guest gets into a state
where DR6.BLD=0 and DEBUGCTL.BLCKDB=0, then AFAICT *any* #VMEXIT will end up
setting guest.DR6.BLD=1 on the subsequent VMRUN, which is just a wee bit problematic
because it means asynchronous #VMEXITs, e.g. for host IRQs, clobber guest state.

I'm still going to post v5 because I'm fairly confident the KVM implementation
is correct, and the bug is easy enough to workaround in the testcases, but needless
to say, I'm not happy at the moment.