On Fri, Jun 13, 2025, Peter Zijlstra wrote:
On Fri, Jun 13, 2025 at 12:01:16AM -0700, Xin Li (Intel) wrote:
While at it, replace the hardcoded debug register number 7 with the
existing DR_CONTROL macro for clarity.
Yeah, not really a fan of that... IMO that obfuscates the code more than
it helps, consider:
+1, and NAK to the KVM changes.
Pretty much everything in KVM deals with the
"raw" names. The use of dr6 and dr7 is pervasive throughout the VMX and SVM
architectures:
vmcs.GUEST_DR7
vmcb.save.dr6
vmcb.save.dr7
And is cemented in KVM's uAPI:
kvm_debug_exit_arch.dr6
kvm_debug_exit_arch.dr7
kvm_debugregs.dr6
kvm_debugregs.dr7
Using DR_STATUS and DR_CONTROL is not an improvement when everything else is using
'6' and '7'. E.g. I skipped the changelog and was very confused by the '6' =>
DR_STATUS change in the next patch.
And don't even think about renaming the prefixes on these :-)
#define DR6_BUS_LOCK (1 << 11)
#define DR6_BD (1 << 13)
#define DR6_BS (1 << 14)
#define DR6_BT (1 << 15)
#define DR6_RTM (1 << 16)
/*
* DR6_ACTIVE_LOW combines fixed-1 and active-low bits.
* We can regard all the bits in DR6_FIXED_1 as active_low bits;
* they will never be 0 for now, but when they are defined
* in the future it will require no code change.
*
* DR6_ACTIVE_LOW is also used as the init/reset value for DR6.
*/
#define DR6_ACTIVE_LOW 0xffff0ff0
#define DR6_VOLATILE 0x0001e80f
#define DR6_FIXED_1 (DR6_ACTIVE_LOW & ~DR6_VOLATILE)
#define DR7_BP_EN_MASK 0x000000ff
#define DR7_GE (1 << 9)
#define DR7_GD (1 << 13)
#define DR7_FIXED_1 0x00000400
#define DR7_VOLATILE 0xffff2bff