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

[Shivansh Dhiman <shivansh.dhiman@amd.com>]

On 26-09-26 04:31, Sean Christopherson wrote:
> 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 reproduced this on Turin with a small KUT test and a trace_printk() of
VMCB.DR6/DEBUGCTL around VMRUN. In each log, the first #VMEXIT (0x26) is
the read_dr6(), which re-executes after the VMRUN.


(1) BLCKDB=1: DR6.BLD=0 is preserved

	wrmsr(DEBUGCTL, BLCKDB);
	write_dr6(0xffff07f0);		/* DR6.BLD=0 */
	cpuid(0);			/* unrelated #VMEXIT */
	read_dr6();			/* -> ffff07f0 */

  #VMEXIT: exit_code=26, vmcb dr6=ffff0ff0
  VMRUN:   vmcb dr6=ffff07f0, dbgctl=4, v_lbr=1
  #VMEXIT: exit_code=7b, vmcb dr6=ffff07f0

As expected.


(2) BLCKDB=0: DR6.BLD=0 is lost

	/* KUT test continued from above */
	write_dr6(0xffff07f0);		/* DR6.BLD=0 */
	wrmsr(DEBUGCTL, 0);
	cpuid(0);			/* unrelated #VMEXIT */
	read_dr6();			/* -> ffff0ff0 */

  #VMEXIT: exit_code=26, vmcb dr6=ffff0ff0
  VMRUN:   vmcb dr6=ffff07f0, dbgctl=0, v_lbr=0
  #VMEXIT: exit_code=7b, vmcb dr6=ffff07f0

KVM loads BLD=0, yet the guest reads BLD=1, so KVM isn't the one setting it.
The VMCB still shows BLD=0 at the next #VMEXIT, though.


(3) BLCKDB=1 again: DR6.BLD=0 comes back

	/* KUT test continued from above */
	wrmsr(DEBUGCTL, BLCKDB);
	read_dr6();			/* -> ffff07f0 */

  #VMEXIT: exit_code=26, vmcb dr6=ffff0ff0
  VMRUN:   vmcb dr6=ffff07f0, dbgctl=4, v_lbr=1
  #VMEXIT: exit_code=7b, vmcb dr6=ffff07f0

At the last #VMEXIT in (2), KVM saved VMCB.DR6 (BLD=0) into its copy of the
guest's DR6. Here it reloads that copy, now with BLCKDB=1, and the guest
sees BLD=0 again. So in this sequence BLD=0 was "hidden" from the guest while
BLCKDB=0, but survived in KVM's saved state.

---

I wanted to understand the practical side better, since I may well be missing
something. My reading of APM 13.1.3.6 is that the processor clears DR6.BLD
only for a bus lock #DB (so only while BLCKDB=1), and that system software
then sets it back to 1 before returning to the interrupted task. I'm not
sure if any software is intended to work by clearing DR6.BLD themselves.

Are there any flows where a guest can end up with DR6.BLD=0 and BLCKDB=0? That
would help me understand where this bites.

-Shivansh

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