kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4 0/2] Fix DR6/DR7 initialization
@ 2025-06-20 23:15 Xin Li (Intel)
  2025-06-20 23:15 ` [PATCH v4 1/2] x86/traps: Initialize DR6 by writing its architectural reset value Xin Li (Intel)
  2025-06-20 23:15 ` [PATCH v4 2/2] x86/traps: Initialize DR7 " Xin Li (Intel)
  0 siblings, 2 replies; 12+ messages in thread
From: Xin Li (Intel) @ 2025-06-20 23:15 UTC (permalink / raw)
  To: linux-kernel, kvm, stable
  Cc: tglx, mingo, bp, dave.hansen, x86, hpa, seanjc, pbonzini, peterz,
	sohil.mehta, brgerst, tony.luck, fenghuay

Sohil reported seeing a split lock warning when running a test that
generates userspace #DB:

  x86/split lock detection: #DB: sigtrap_loop_64/4614 took a bus_lock trap at address: 0x4011ae


We investigated the issue and figured out:

  1) The warning is a false positive.

  2) It is not caused by the test itself.

  3) It occurs even when Bus Lock Detection (BLD) is disabled.

  4) It only happens on the first #DB on a CPU.


And the root cause is, at boot time, Linux zeros DR6.  This leads to
different DR6 values depending on whether the CPU supports BLD:

  1) On CPUs with BLD support, DR6 becomes 0xFFFF07F0 (bit 11, DR6.BLD,
     is cleared).

  2) On CPUs without BLD, DR6 becomes 0xFFFF0FF0.

Since only BLD-induced #DB exceptions clear DR6.BLD and other debug
exceptions leave it unchanged, even if the first #DB is unrelated to
BLD, DR6.BLD is still cleared.  As a result, such a first #DB is
misinterpreted as a BLD #DB, and a false warning is triggerred.


Fix the bug by initializing DR6 by writing its architectural reset
value at boot time.

DR7 suffers from a similar issue, apply the same fix.


This patch set is based on tip/x86/urgent branch as of today.

Link to the previous patch set v3:
https://lore.kernel.org/all/20250618172723.1651465-1-xin@zytor.com/


Change in v4:
*) Cc stable in the DR7 initialization patch for backporting, just in
   case bit 10 of DR7 has become unreserved on new hardware, even
   though clearing it doesn't currently cause any real issues (Dave
   Hansen).


Xin Li (Intel) (2):
  x86/traps: Initialize DR6 by writing its architectural reset value
  x86/traps: Initialize DR7 by writing its architectural reset value

 arch/x86/include/asm/debugreg.h      | 19 ++++++++++++----
 arch/x86/include/asm/kvm_host.h      |  2 +-
 arch/x86/include/uapi/asm/debugreg.h | 21 ++++++++++++++++-
 arch/x86/kernel/cpu/common.c         | 24 ++++++++------------
 arch/x86/kernel/kgdb.c               |  2 +-
 arch/x86/kernel/process_32.c         |  2 +-
 arch/x86/kernel/process_64.c         |  2 +-
 arch/x86/kernel/traps.c              | 34 +++++++++++++++++-----------
 arch/x86/kvm/x86.c                   |  4 ++--
 9 files changed, 72 insertions(+), 38 deletions(-)


base-commit: 2aebf5ee43bf0ed225a09a30cf515d9f2813b759
-- 
2.49.0


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2025-06-24  2:43 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-20 23:15 [PATCH v4 0/2] Fix DR6/DR7 initialization Xin Li (Intel)
2025-06-20 23:15 ` [PATCH v4 1/2] x86/traps: Initialize DR6 by writing its architectural reset value Xin Li (Intel)
2025-06-23  6:49   ` Ethan Zhao
2025-06-23  8:14     ` H. Peter Anvin
2025-06-24  1:06       ` Ethan Zhao
2025-06-23 16:34     ` Xin Li
2025-06-24  1:19       ` Ethan Zhao
2025-06-24  1:32         ` H. Peter Anvin
2025-06-20 23:15 ` [PATCH v4 2/2] x86/traps: Initialize DR7 " Xin Li (Intel)
2025-06-24  1:41   ` Ethan Zhao
2025-06-24  1:53     ` H. Peter Anvin
2025-06-24  2:43       ` Ethan Zhao

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).