In the x86's debug_regs test, add a test case to cover the scenario where
single-step with STI in VMX sets the 'BS' bit in pending debug
exceptions for #DB interception and instruction emulation in both cases.
Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
---
.../selftests/kvm/include/x86/processor.h | 3 +-
tools/testing/selftests/kvm/x86/debug_regs.c | 41 +++++++++++++++++--
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h
index 488d516c4f6f..f5827cca813e 100644
--- a/tools/testing/selftests/kvm/include/x86/processor.h
+++ b/tools/testing/selftests/kvm/include/x86/processor.h
@@ -34,7 +34,8 @@ extern uint64_t guest_tsc_khz;
#define NMI_VECTOR 0x02
-#define X86_EFLAGS_FIXED (1u << 1)
+#define X86_EFLAGS_FIXED (1u << 1)
+#define X86_EFLAGS_TF (1u << 8)
#define X86_CR4_VME (1ul << 0)
#define X86_CR4_PVI (1ul << 1)
diff --git a/tools/testing/selftests/kvm/x86/debug_regs.c b/tools/testing/selftests/kvm/x86/debug_regs.c
index ba80b77c2869..60dea0116b21 100644
--- a/tools/testing/selftests/kvm/x86/debug_regs.c
+++ b/tools/testing/selftests/kvm/x86/debug_regs.c
@@ -15,11 +15,31 @@
#define IRQ_VECTOR 0xAA
+#define CAST_TO_RIP(v) ((unsigned long long)&(v))
+
/* For testing data access debug BP */
uint32_t 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: unexpected rip 0x%lx (should be 0x%lx)",
+ regs->rip, target_rips[count]);
+ regs->rflags &= ~X86_EFLAGS_TF;
+ count++;
+}
+
+static void guest_irq_handler(struct ex_regs *regs)
+{
+}
static void guest_code(void)
{
@@ -69,13 +89,25 @@ static void guest_code(void)
if (is_forced_emulation_enabled) {
/* DR6.BD test for emulation */
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");
}
GUEST_DONE();
}
-#define CAST_TO_RIP(v) ((unsigned long long)&(v))
-
static void vcpu_skip_insn(struct kvm_vcpu *vcpu, int insn_len)
{
struct kvm_regs regs;
@@ -110,6 +142,9 @@ int main(void)
vm = vm_create_with_one_vcpu(&vcpu, guest_code);
run = vcpu->run;
+ vm_install_exception_handler(vm, DB_VECTOR, guest_db_handler);
+ vm_install_exception_handler(vm, IRQ_VECTOR, guest_irq_handler);
+
/* Test software BPs - int3 */
memset(&debug, 0, sizeof(debug));
debug.control = KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP;
--
2.31.1
On Wed, Sep 10, 2025, Hou Wenlong wrote:
> #define IRQ_VECTOR 0xAA
>
> +#define CAST_TO_RIP(v) ((unsigned long long)&(v))
> +
> /* For testing data access debug BP */
> uint32_t 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: unexpected rip 0x%lx (should be 0x%lx)",
> + regs->rip, target_rips[count]);
> + regs->rflags &= ~X86_EFLAGS_TF;
> + count++;
> +}
> +
> +static void guest_irq_handler(struct ex_regs *regs)
> +{
> +}
>
> static void guest_code(void)
> {
> @@ -69,13 +89,25 @@ static void guest_code(void)
> if (is_forced_emulation_enabled) {
> /* DR6.BD test for emulation */
> 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");
> }
>
> GUEST_DONE();
> }
>
> -#define CAST_TO_RIP(v) ((unsigned long long)&(v))
> -
> static void vcpu_skip_insn(struct kvm_vcpu *vcpu, int insn_len)
> {
> struct kvm_regs regs;
> @@ -110,6 +142,9 @@ int main(void)
> vm = vm_create_with_one_vcpu(&vcpu, guest_code);
> run = vcpu->run;
>
> + vm_install_exception_handler(vm, DB_VECTOR, guest_db_handler);
> + vm_install_exception_handler(vm, IRQ_VECTOR, guest_irq_handler);
But the IRQ should never be taken thanks to the CLI in the STI shadow. I.e.
installing a dummy handler could mask failures, no?
> +
> /* Test software BPs - int3 */
> memset(&debug, 0, sizeof(debug));
> debug.control = KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP;
> --
> 2.31.1
>
On Fri, Dec 05, 2025 at 10:23:42AM -0800, Sean Christopherson wrote:
> On Wed, Sep 10, 2025, Hou Wenlong wrote:
> > #define IRQ_VECTOR 0xAA
> >
> > +#define CAST_TO_RIP(v) ((unsigned long long)&(v))
> > +
> > /* For testing data access debug BP */
> > uint32_t 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: unexpected rip 0x%lx (should be 0x%lx)",
> > + regs->rip, target_rips[count]);
> > + regs->rflags &= ~X86_EFLAGS_TF;
> > + count++;
> > +}
> > +
> > +static void guest_irq_handler(struct ex_regs *regs)
> > +{
> > +}
> >
> > static void guest_code(void)
> > {
> > @@ -69,13 +89,25 @@ static void guest_code(void)
> > if (is_forced_emulation_enabled) {
> > /* DR6.BD test for emulation */
> > 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");
> > }
> >
> > GUEST_DONE();
> > }
> >
> > -#define CAST_TO_RIP(v) ((unsigned long long)&(v))
> > -
> > static void vcpu_skip_insn(struct kvm_vcpu *vcpu, int insn_len)
> > {
> > struct kvm_regs regs;
> > @@ -110,6 +142,9 @@ int main(void)
> > vm = vm_create_with_one_vcpu(&vcpu, guest_code);
> > run = vcpu->run;
> >
> > + vm_install_exception_handler(vm, DB_VECTOR, guest_db_handler);
> > + vm_install_exception_handler(vm, IRQ_VECTOR, guest_irq_handler);
>
> But the IRQ should never be taken thanks to the CLI in the STI shadow. I.e.
> installing a dummy handler could mask failures, no?
>
Uh, I remember why I need to install the dummy IRQ handler. There is a
single-step #DB after STI, so the #DB delivery removes the interrupt
shadow, and then the pending interrupt will be delivered after IRET.
I'll move the IRQ handler registration after the KVM_GUESTDBG_BLOCKIRQ
testcase.
> > +
> > /* Test software BPs - int3 */
> > memset(&debug, 0, sizeof(debug));
> > debug.control = KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP;
> > --
> > 2.31.1
> >
On Fri, Dec 05, 2025 at 10:23:42AM -0800, Sean Christopherson wrote:
> On Wed, Sep 10, 2025, Hou Wenlong wrote:
> > #define IRQ_VECTOR 0xAA
> >
> > +#define CAST_TO_RIP(v) ((unsigned long long)&(v))
> > +
> > /* For testing data access debug BP */
> > uint32_t 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: unexpected rip 0x%lx (should be 0x%lx)",
> > + regs->rip, target_rips[count]);
> > + regs->rflags &= ~X86_EFLAGS_TF;
> > + count++;
> > +}
> > +
> > +static void guest_irq_handler(struct ex_regs *regs)
> > +{
> > +}
> >
> > static void guest_code(void)
> > {
> > @@ -69,13 +89,25 @@ static void guest_code(void)
> > if (is_forced_emulation_enabled) {
> > /* DR6.BD test for emulation */
> > 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");
> > }
> >
> > GUEST_DONE();
> > }
> >
> > -#define CAST_TO_RIP(v) ((unsigned long long)&(v))
> > -
> > static void vcpu_skip_insn(struct kvm_vcpu *vcpu, int insn_len)
> > {
> > struct kvm_regs regs;
> > @@ -110,6 +142,9 @@ int main(void)
> > vm = vm_create_with_one_vcpu(&vcpu, guest_code);
> > run = vcpu->run;
> >
> > + vm_install_exception_handler(vm, DB_VECTOR, guest_db_handler);
> > + vm_install_exception_handler(vm, IRQ_VECTOR, guest_irq_handler);
>
> But the IRQ should never be taken thanks to the CLI in the STI shadow. I.e.
> installing a dummy handler could mask failures, no?
>
Yes, this also breaks the testcase regarding KVM_GUESTDBG_BLOCKIRQ.
Sorry, I forgot why I added this, as you said there should be no IRQ
delivered due to the STI shadow. :(
I'll remove it in the next version.
Thanks!
> > +
> > /* Test software BPs - int3 */
> > memset(&debug, 0, sizeof(debug));
> > debug.control = KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP;
> > --
> > 2.31.1
> >
© 2016 - 2026 Red Hat, Inc.