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