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