Re: [PATCH 4/7] KVM: x86: Consolidate KVM_GUESTDBG_SINGLESTEP check into the kvm_inject_emulated_db()

[Sean Christopherson <seanjc@google.com>]

On Sun, Dec 14, 2025, Hou Wenlong wrote:
> On Fri, Dec 12, 2025 at 09:53:20AM -0800, Sean Christopherson wrote:
> > On Fri, Dec 12, 2025, Hou Wenlong wrote:
> > > On Thu, Dec 11, 2025 at 09:19:39AM -0800, Sean Christopherson wrote:
> > > > On Thu, Dec 11, 2025, Hou Wenlong wrote:
> > > > +static noinline unsigned long singlestep_with_code_db(void)
> > > > +{
> > > > +	unsigned long start;
> > > > +
> > > > +	asm volatile (
> > > > +		"lea 1f(%%rip), %0\n\t"
> > > > +		"mov %0, %%dr2\n\t"
> > > > +		"mov $" xstr(DR7_FIXED_1 | DR7_EXECUTE_DRx(2) | DR7_GLOBAL_ENABLE_DR2) ", %0\n\t"
> > > > +		"mov %0, %%dr7\n\t"
> > > > +		"pushf\n\t"
> > > > +		"pop %%rax\n\t"
> > > > +		"or $(1<<8),%%rax\n\t"
> > > > +		"push %%rax\n\t"
> > > > +		"popf\n\t"
> > > > +		"and $~(1<<8),%%rax\n\t"
> > > In my previous understanding, I thought there would be two #DBs
> > > generated at the instruction boundary. First, the single-step trap #DB
> > > would be handled, and then, when resuming to start the new instruction,
> > > it would check for the code breakpoint and generate a code fault #DB.
> > > However, it turns out that the check for the code breakpoint happened
> > > before the instruction boundary. 
> > 
> > Yeah, that's what I was trying to explain by describing code breakpoint as fault-like.
> > 
> > > I also see in the kernel hardware breakpoint handler that it notes that code
> > > breakpoints and single-step can be detected together. Is this due to
> > > instruction prefetch?
> > 
> > Nope, it's just how #DBs work, everything pending gets smushed together.  Note,
> > data #DBs can also be coincident.  E.g. it's entirely possible that you could
> > observe a code breakpoint, a data breakpoint, and a single-step breakpoint in a
> > single #DB.
> > 
> > > If we want to emulate the hardware behavior in the emulator, does that
> > > mean we need to check for code breakpoints in kvm_vcpu_do_single_step()
> > > and set the DR_TRAP_BITS along with the DR6_BS bit?
> > 
> > Hmm, ya, I think so?  I don't think the CPU will fetch and merge the imminent
> > code #DB with the injected single-step #DB.
> Um, I have one more question: what do you mean when you say that
> kvm_vcpu_check_code_breakpoint() doesn't account for RFLAGS.TF?

I was pointing out that if KVM is emulating multiple instructions without
entering the guest, then I'm pretty sure kvm_vcpu_check_code_breakpoint() would
fail to detect a coincident single-step #DB.  kvm_vcpu_check_code_breakpoint()
may not be the right place to try and handle that though.