On 6/5/2025 2:51 PM, Sohil Mehta wrote:
Xin Li (Intel) (2):
x86/fred/signal: Prevent single-step upon ERETU completion
selftests/x86: Add a test to detect infinite sigtrap handler loop
I tested the patches on a machine that supports FRED. The results are as
expected:
Seeing a split lock warning when running the test:
x86/split lock detection: #DB: sigtrap_loop_64/4614 took a bus_lock trap
at address: 0x4011ae
Wanted to get this out sooner for awareness. Will figure out more
details and send out an update.
We investigated this issue, and figured out the reason why we see a
split lock warning when running the test:
1) The warning is not caused by the test.
2) It's a false warning.
3) It happens even when bus lock detection (BLD) is not enabled.
4) It happens only on the first #DB on a CPU.
The root cause is that Linux writes 0 to DR6 at boot time, which results
in different values in DR6 depending on whether they support BLD or not.
On CPUs that support BLD, writing 0 to DR6 sets DR6 to 0xFFFF07F0, i.e.,
bit 11 of DR6, its BLD flag, is cleared. Otherwise 0xFFFF0FF0.
But Intel SDM says, other than BLD induced #DB, DR6.BLD is not modified.
To avoid confusion in identifying debug exceptions, software debug-
exception handlers should set bit 11 to 1 before returning. DR6.BLD
is always 1 if the processor does not support OS bus-lock detection.
Because Linux clears DR6.BLD on CPUs that support BLD at boot time, the
first #DB will be INCORRECTLY interpreted as a BLD #DB, thus the
warning, no matter whether BLD is enabled or not.
We will be working on a fix to initialize DR6 and DR7 with their
architectural reset values instead of 0s.
Thanks!
Xin
