From: Sean Christopherson <seanjc@google.com>
To: Hou Wenlong <houwenlong.hwl@antgroup.com>
Cc: kvm@vger.kernel.org, Lai Jiangshan <jiangshan.ljs@antgroup.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 9/9] KVM: selftests: Verify 'BS' bit checking in pending debug exception state during VM-Entry
Date: Thu, 14 May 2026 11:51:59 -0700 [thread overview]
Message-ID: <agYZz7D6OXsEIEYF@google.com> (raw)
In-Reply-To: <20260514053105.GA109150@k08j02272.eu95sqa>
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...).
next prev parent reply other threads:[~2026-05-14 18:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-18 14:00 [PATCH v2 0/9] KVM: x86: Improve the handling of debug exceptions during instruction emulation Hou Wenlong
2025-12-18 14:00 ` [PATCH v2 8/9] KVM: selftests: Verify guest debug DR7.GD checking " Hou Wenlong
2025-12-18 14:00 ` [PATCH v2 9/9] KVM: selftests: Verify 'BS' bit checking in pending debug exception state during VM-Entry Hou Wenlong
2026-05-13 23:14 ` Sean Christopherson
2026-05-14 5:31 ` Hou Wenlong
2026-05-14 18:51 ` Sean Christopherson [this message]
2026-05-11 15:45 ` [PATCH v2 0/9] KVM: x86: Improve the handling of debug exceptions during instruction emulation Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agYZz7D6OXsEIEYF@google.com \
--to=seanjc@google.com \
--cc=houwenlong.hwl@antgroup.com \
--cc=jiangshan.ljs@antgroup.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox