Re: [PATCH v3 10/10] KVM: selftests: Verify VMX's GUEST_PENDING_DBG_EXCEPTIONS.BS Consistency Check
From: Sean Christopherson
Date: Wed May 20 2026 - 13:05:12 EST
On Fri, May 15, 2026, Sean Christopherson wrote:
> From: Hou Wenlong <houwenlong.hwl@xxxxxxxxxxxx>
>
> In x86's debug_regs test, add a test case to cover the scenario where a
> single-step #DB occurs in an STI-shadow, in which case KVM needs to stuff
> vmcs.GUEST_PENDING_DBG_EXCEPTIONS.BS in order to satisfy a flawed VM-Entry
> Consistency Check.
>
> Wire up an IRQ handler to gain a bit of bonus coverage, as the subsequent
> IRET from the #DB sets RFLAGS.IF, but *without* STI-blocking, and so the
> pending IRQ is expected on the instruction immediately following STI.
>
> Signed-off-by: Hou Wenlong <houwenlong.hwl@xxxxxxxxxxxx>
> [sean: expect the IRQ on the CLI, and explain why]
> Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> ---
> tools/testing/selftests/kvm/x86/debug_regs.c | 64 ++++++++++++++++++--
> 1 file changed, 60 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/x86/debug_regs.c b/tools/testing/selftests/kvm/x86/debug_regs.c
> index ee9d0f3a5807..6299e921dc27 100644
> --- a/tools/testing/selftests/kvm/x86/debug_regs.c
> +++ b/tools/testing/selftests/kvm/x86/debug_regs.c
> @@ -15,11 +15,46 @@
>
> #define IRQ_VECTOR 0xAA
>
> +#define CAST_TO_RIP(v) ((unsigned long long)&(v))
> +
> /* For testing data access debug BP */
> u32 guest_value;
>
> extern unsigned char sw_bp, hw_bp, write_data, ss_start, bd_start;
> -extern unsigned char fep_bd_start;
> +extern unsigned char fep_bd_start, fep_sti_start, fep_sti_end;
> +
> +static void guest_db_handler(struct ex_regs *regs)
> +{
> + static int count;
> + unsigned long target_rips[2] = {
> + CAST_TO_RIP(fep_sti_start),
> + CAST_TO_RIP(fep_sti_end),
> + };
> +
> + __GUEST_ASSERT(regs->rip == target_rips[count],
> + "STI[%u]: unexpected rip 0x%lx (should be 0x%lx)",
> + count, regs->rip, target_rips[count]);
> + regs->rflags &= ~X86_EFLAGS_TF;
> + count++;
> +}
> +
> +static void guest_irq_handler(struct ex_regs *regs)
> +{
> + /*
> + * The pending IRQ should finally be take when KVM_GUESTDBG_BLOCKIRQ is
> + * cleared and IRQs are enabled. Note, the IRQ is expected to arrive
> + * on the instruction immediately after STI, even though its in an STI
> + * shadow. Because the next instruction has a coincident #DB, and #DBs
> + * are not subject to STI-blocking, the #DB will push RFLAGS.IF=1 on
> + * the stack, and the eventual IRET will unmask IRQs and obliterate the
> + * STI shadow in the process.
> + */
> + unsigned long target_rip = CAST_TO_RIP(fep_sti_start);
> +
> + __GUEST_ASSERT(regs->rip == target_rip,
> + "IRQ: unexpected rip 0x%lx (should be 0x%lx)",
> + regs->rip, target_rip);
>From Sashiko:
: Is an End of Interrupt (EOI) acknowledgment required here?
:
: The handler is triggered by an APIC interrupt injected earlier in the test,
: but does not write to the APIC_EOI register to acknowledge it.
:
: While it might not fail this specific test since it ends immediately after,
: does failing to send an EOI leave the interrupt permanently marked as
: in-service in the local APIC state machine?
Yes, this will leave the IRQ dangling in the ISR. It doesn't really matter, but
I'll throw in a:
x2apic_write_reg(APIC_EOI, 0);
when applying.
> +}
>
> static void guest_code(void)
> {
> @@ -66,14 +101,32 @@ static void guest_code(void)
> /* DR6.BD test */
> asm volatile("bd_start: mov %%dr0, %%rax" : : : "rax");
>
> - if (is_forced_emulation_enabled)
> + /*
> + * Note, the IRET from the #DB that occurs in the below STI-shadow will
> + * unmask IRQs, i.e. the pending interrupt will be delivered after #DB
> + * handling, on the CLI!
> + */
> + if (is_forced_emulation_enabled) {
> asm volatile(KVM_FEP "fep_bd_start: mov %%dr0, %%rax" : : : "rax");
>
> + /* pending debug exceptions for emulation */
> + asm volatile("pushf\n\t"
> + "orq $" __stringify(X86_EFLAGS_TF) ", (%rsp)\n\t"
> + "popf\n\t"
> + "sti\n\t"
> + "fep_sti_start:"
> + "cli\n\t"
> + "pushf\n\t"
> + "orq $" __stringify(X86_EFLAGS_TF) ", (%rsp)\n\t"
> + "popf\n\t"
> + KVM_FEP "sti\n\t"
> + "fep_sti_end:"
> + "cli\n\t");
> + }
> +
Also from Sashiko:
: Does the test verify that the expected #DB and IRQ events actually occurred?
:
: The assertions are placed inside guest_db_handler() and guest_irq_handler(),
: but if a bug causes the exceptions to be dropped completely, the guest
: will simply proceed to execute GUEST_DONE() without error.
:
: Should there be a shared state variable to assert that the handlers fired
: the expected number of times before concluding the test?
Another "yes". I'll add an assert that the IRQ actually fired.