Re: [PATCH v2 9/9] KVM: selftests: Verify 'BS' bit checking in pending debug exception state during VM-Entry

[Sean Christopherson <seanjc@google.com>]

On Thu, May 14, 2026, Hou Wenlong wrote:
> On Wed, May 13, 2026 at 04:14:14PM -0700, Sean Christopherson wrote:
> > On Thu, Dec 18, 2025, Hou Wenlong wrote:
> > > +static void guest_irq_handler(struct ex_regs *regs)
> > > +{
> > > +	unsigned long target_rip = CAST_TO_RIP(fep_bd_start);
> > > +
> > > +	__GUEST_ASSERT(regs->rip == target_rip, "IRQ: unexpected rip 0x%lx (should be 0x%lx)",
> > > +		       regs->rip, target_rip);
> > 
> > This is wrong, and the test fails with your series applied verbatim.  The IRQ
> > will arrive at fep_sti_start, because RFLAGS.IF=0 from the CLI at the end of the
> > ss_start block, and remains that way across fep_bd_start.   And to make things
> > even more confusing, the IRQ arrives on the CLI even though it's in an STI shadow
> > due to #DBs not being subjected to _STI_ shadows on Intel, only to MOV-SS/POP-SS
> > shadows.  I.e. the #DB lands on CLI, pushes RFLAGS.IF=1 on the stack, and then
> > the subsequent IRET from guest_db_handler() fully unmasks IRQs, and voila.
> 
> Yes, the RIP here should be 'fep_sti_start'. This was a stupid mistake,
> and I’m very sorry about that. In my reply to v1[0] I explained why an IRQ
> handler is needed, so in v2 I added comments and an additional check,
> and I tested it before sending. However, it looks like the patch differs
> from what I had locally—my code management was a bit messy.

...

> I have tested it on both Intel and AMD. Please let me know if I should
> resend a v3 of this patch.

No need, I'm actually going to send a v3 of the entire series (beleated feedback
on patch 6 incoming...).