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

[Sean Christopherson <seanjc@google.com>]

On Fri, Oct 02, 2026, Shivansh Dhiman wrote:
> On 26-09-26 04:31, Sean Christopherson wrote:
> (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.

Yep.  This is why I view this as a hardware/ucode flaw.

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

It has to, because that's effectively what VMRUN does by loading DR6.  It's not
as straightforward as MOV DR6 (obviously), but for all intents and purposes it's
still a software write.

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

In practice, I doubt it will be problematic.  But it's not completely absurd that
software might do something like temporarily disable DEBUGCTL.BUS_LOCK at the
start of its #DB handler, before reading DR6.  That would work on bare metal and
*usually* work in a VM, but would cause the guest to "miss" a Bus Lock #DB if a
#VMEXIT hit between disabling DEBUGCTL.BUS_LOCK and reading DR6.