The current logic used to update %dr6 when injecting #DB is buggy.
The SDM/APM documention on %dr6 updates is far from ideal, but does at least
make clear that it's non-trivial. The actual behaviour is to overwrite
B{0..3} and accumulate all other bits.
Introduce x86_merge_dr6() to perform the operaton properly.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Wei Liu <wl@xen.org>
CC: Jinoh Kang <jinoh.kang.kr@gmail.com>
v2:
* Extend commit message
---
xen/arch/x86/debug.c | 20 ++++++++++++++++++++
xen/arch/x86/include/asm/debugreg.h | 7 +++++++
xen/arch/x86/include/asm/x86-defns.h | 7 +++++++
3 files changed, 34 insertions(+)
diff --git a/xen/arch/x86/debug.c b/xen/arch/x86/debug.c
index 127fe83021cd..bfcd83ea4d0b 100644
--- a/xen/arch/x86/debug.c
+++ b/xen/arch/x86/debug.c
@@ -3,6 +3,7 @@
* Copyright (C) 2023 XenServer.
*/
#include <xen/kernel.h>
+#include <xen/lib.h>
#include <xen/lib/x86/cpu-policy.h>
@@ -28,6 +29,25 @@ unsigned int x86_adj_dr6_rsvd(const struct cpu_policy *p, unsigned int dr6)
return dr6;
}
+unsigned int x86_merge_dr6(const struct cpu_policy *p, unsigned int dr6,
+ unsigned int new)
+{
+ /* Flip dr6 to have positive polarity. */
+ dr6 ^= X86_DR6_DEFAULT;
+
+ /* Sanity check that only known values are passed in. */
+ ASSERT(!(dr6 & ~X86_DR6_KNOWN_MASK));
+ ASSERT(!(new & ~X86_DR6_KNOWN_MASK));
+
+ /* Breakpoint matches are overridden. All other bits accumulate. */
+ dr6 = (dr6 & ~X86_DR6_BP_MASK) | new;
+
+ /* Flip dr6 back to having default polarity. */
+ dr6 ^= X86_DR6_DEFAULT;
+
+ return x86_adj_dr6_rsvd(p, dr6);
+}
+
unsigned int x86_adj_dr7_rsvd(const struct cpu_policy *p, unsigned int dr7)
{
unsigned int zeros = X86_DR7_ZEROS;
diff --git a/xen/arch/x86/include/asm/debugreg.h b/xen/arch/x86/include/asm/debugreg.h
index 39ba312b84ee..e98a9ce977fa 100644
--- a/xen/arch/x86/include/asm/debugreg.h
+++ b/xen/arch/x86/include/asm/debugreg.h
@@ -89,4 +89,11 @@ struct cpu_policy;
unsigned int x86_adj_dr6_rsvd(const struct cpu_policy *p, unsigned int dr6);
unsigned int x86_adj_dr7_rsvd(const struct cpu_policy *p, unsigned int dr7);
+/*
+ * Merge new bits into dr6. 'new' is always given in positive polarity,
+ * matching the Intel VMCS PENDING_DBG semantics.
+ */
+unsigned int x86_merge_dr6(const struct cpu_policy *p, unsigned int dr6,
+ unsigned int new);
+
#endif /* _X86_DEBUGREG_H */
diff --git a/xen/arch/x86/include/asm/x86-defns.h b/xen/arch/x86/include/asm/x86-defns.h
index 5838631ef634..edfecc89bd08 100644
--- a/xen/arch/x86/include/asm/x86-defns.h
+++ b/xen/arch/x86/include/asm/x86-defns.h
@@ -116,6 +116,13 @@
#define X86_DR6_BT (_AC(1, UL) << 15) /* Task switch */
#define X86_DR6_RTM (_AC(1, UL) << 16) /* #DB/#BP in RTM region (INV) */
+#define X86_DR6_BP_MASK \
+ (X86_DR6_B0 | X86_DR6_B1 | X86_DR6_B2 | X86_DR6_B3)
+
+#define X86_DR6_KNOWN_MASK \
+ (X86_DR6_BP_MASK | X86_DR6_BLD | X86_DR6_BD | X86_DR6_BS | \
+ X86_DR6_BT | X86_DR6_RTM)
+
#define X86_DR6_ZEROS _AC(0x00001000, UL) /* %dr6 bits forced to 0 */
#define X86_DR6_DEFAULT _AC(0xffff0ff0, UL) /* Default %dr6 value */
--
2.30.2
On 15.09.2023 22:36, Andrew Cooper wrote: > The current logic used to update %dr6 when injecting #DB is buggy. > > The SDM/APM documention on %dr6 updates is far from ideal, but does at least > make clear that it's non-trivial. The actual behaviour is to overwrite > B{0..3} and accumulate all other bits. As mentioned before, I'm okay to ack this patch provided it is explicitly said where the information is coming from. Just saying that SDM/PM are incomplete isn't enough, sorry. With that added (can't really be R-b, I'm afraid): Acked-by: Jan Beulich <jbeulich@suse.com> Jan
On 18/09/2023 12:37 pm, Jan Beulich wrote: > On 15.09.2023 22:36, Andrew Cooper wrote: >> The current logic used to update %dr6 when injecting #DB is buggy. >> >> The SDM/APM documention on %dr6 updates is far from ideal, but does at least >> make clear that it's non-trivial. The actual behaviour is to overwrite >> B{0..3} and accumulate all other bits. > As mentioned before, I'm okay to ack this patch provided it is explicitly said > where the information is coming from. The information *is* coming from the relevant paragraph of the relevant chapters of the relevant manuals. I don't need to teach programmers how to suck eggs. Nor am I going to quote buggy manuals (corrections are pending for both) as a justification for restating several paragraphs of information as a oneliner. ~Andrew
On 22.09.2023 18:11, Andrew Cooper wrote: > On 18/09/2023 12:37 pm, Jan Beulich wrote: >> On 15.09.2023 22:36, Andrew Cooper wrote: >>> The current logic used to update %dr6 when injecting #DB is buggy. >>> >>> The SDM/APM documention on %dr6 updates is far from ideal, but does at least >>> make clear that it's non-trivial. The actual behaviour is to overwrite >>> B{0..3} and accumulate all other bits. >> As mentioned before, I'm okay to ack this patch provided it is explicitly said >> where the information is coming from. > > The information *is* coming from the relevant paragraph of the relevant > chapters of the relevant manuals. > > I don't need to teach programmers how to suck eggs. Nor am I going to > quote buggy manuals (corrections are pending for both) as a > justification for restating several paragraphs of information as a oneliner. Earlier on you said this to my original request: 'SDM Vol3 18.2.3 Debug Status Register (DR6) says "Certain debug exceptions may clear bits 0-3. The remaining contents of the DR6 register are never cleared by the processor."' "Certain" and "may" do not describe the behavior that your change implements. Hence imo there's still a need to clarify where the extra information is coming from. Pending corrections are of course appreciated; in case you have been told the new wording already, perhaps you could quote that? Jan
On 9/25/23 16:30, Jan Beulich wrote: > On 22.09.2023 18:11, Andrew Cooper wrote: >> On 18/09/2023 12:37 pm, Jan Beulich wrote: >>> On 15.09.2023 22:36, Andrew Cooper wrote: >>>> The current logic used to update %dr6 when injecting #DB is buggy. >>>> >>>> The SDM/APM documention on %dr6 updates is far from ideal, but does at least >>>> make clear that it's non-trivial. The actual behaviour is to overwrite >>>> B{0..3} and accumulate all other bits. >>> As mentioned before, I'm okay to ack this patch provided it is explicitly said >>> where the information is coming from. >> >> The information *is* coming from the relevant paragraph of the relevant >> chapters of the relevant manuals. >> >> I don't need to teach programmers how to suck eggs. Nor am I going to >> quote buggy manuals (corrections are pending for both) as a >> justification for restating several paragraphs of information as a oneliner. > > Earlier on you said this to my original request: > > 'SDM Vol3 18.2.3 Debug Status Register (DR6) says > > "Certain debug exceptions may clear bits 0-3. The remaining contents of > the DR6 register are never cleared by the processor."' > > "Certain" and "may" do not describe the behavior that your change implements. > Hence imo there's still a need to clarify where the extra information is > coming from. Pending corrections are of course appreciated; in case you have > been told the new wording already, perhaps you could quote that? As an outsider's perspective, I think this kind of thing is where selftests really shine. I got the impression that Xen will need to rely on numerous other platform oddities, the documentation of which are often unavailable. Of course, adding a whole new test infrastructure in code freeze is not viable. Maybe I have missed something, but I only see three paths forward here: 1. Reference the most relevant paragraph in SDM/APM, but don't quote it. Keep the current explanation, and state that the manual is vague anyway. 2. Acknowledge that SDM/APM is incomplete, and completely abandon the manual as the *authoritative* source of information. Perhaps embed a sample test program that demonstrates the behavior, if it isn't too long. 3. Actually assert in runtime that DR6 behaves as expected. > > Jan -- Sincerely, Jinoh Kang
On 9/25/23 19:20, Jinoh Kang wrote: > As an outsider's perspective, I think this kind of thing is where selftests > really shine. I got the impression that Xen will need to rely on numerous other > platform oddities, the documentation of which are often unavailable. > > Of course, adding a whole new test infrastructure in code freeze is not viable. > Maybe I have missed something, but I only see three paths forward here: > > 1. Reference the most relevant paragraph in SDM/APM, but don't quote it. > Keep the current explanation, and state that the manual is vague anyway. > > 2. Acknowledge that SDM/APM is incomplete, and completely abandon the manual > as the *authoritative* source of information. Perhaps embed a sample test > program that demonstrates the behavior, if it isn't too long. > > 3. Actually assert in runtime that DR6 behaves as expected. > Just a heads-up; has there been any progress on this part? Please let me know if you need anything. I'm happy to help! -- Sincerely, Jinoh Kang
© 2016 - 2024 Red Hat, Inc.