x86_merge_dr6() is not a no-op when 0 is passed in; it will discard the
previously latched breakpoint bits.
The combination of do_debug()'s manual call to x86_merge_dr6() for external
debuggers, and pv_inject_DB() calling pv_inject_event(), results in two
x86_merge_dr6() calls.
Feed the same pending_dbg in the second time. This makes pv_inject_event()'s
update of dr6 effectively a no-op, retaining the correct breakpoint bits.
Fixes: db39fa4b27ea ("x86/pv: Fix merging of new status bits into %dr6")
Reported-by: Manuel Bouyer <bouyer@antioche.eu.org>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Manuel Bouyer <bouyer@antioche.eu.org>
Now to figure out why my testing didn't spot this...
---
xen/arch/x86/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 22f20629327d..e7b4693415cd 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1823,7 +1823,7 @@ void asmlinkage do_debug(struct cpu_user_regs *regs)
return;
}
- pv_inject_DB(0 /* N/A, already merged */);
+ pv_inject_DB(dr6 ^ X86_DR6_DEFAULT);
}
void asmlinkage do_entry_CP(struct cpu_user_regs *regs)
base-commit: 6cfe3ae346fc84fbd4380fc45c70780935da590a
--
2.39.5