On Mon, Feb 24, 2025, Ravi Bangoria wrote: > As per the AMD APM[1], DR6[BusLockDetect] bit is unmodified for any source > of #DB exception other than Bus Lock (and AMD HW is working correctly as > per the spec). > > KUT debug test initializes DR6[BusLockDetect] with 0 before executing each > test and thus the bit remains 0 at the #DB exception for sources other > than Bus Lock. Since DR6[BusLockDetect] bit has opposite polarity, as in, > value 0 indicates the condition, KUT tests are interpreting it as #DB due > to Bus Lock and thus they are failing. > > Fix this by initializing DR6 with a valid default value before running the > test. The test is weird, but as-is it's correct. The APM does a poor job of stating the exact behavior, but DR6[11] should never go to '0' if BusLockTrap is disabled, even if software explicitly writes '0'. Any other behavior would break backwards compatibility with existing software (as evidenced by the test failing). Editing to omit irrelevant snippets: Software enables bus lock trap by setting DebugCtl MSR[BLCKDB] (bit 2) to 1 When bus lock trap is enabled, ... The processor indicates that this #DB was caused by a bus lock by clearing DR6[BLD] (bit 11). DR6[11] previously had been defined to be always 1. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The test fails because the host leaves DebugCtl.BLCKDB, a.k.a. BusLockDetect, enabled. With my to-be-posted change to manually clear DebugCtl prior to VMRUN, the test passes.
