On 03/04/2024 3:50 pm, Marek Marczykowski-Górecki wrote: > Hi, > > I've noticed that tools/tests/tsx/test-tsx fails on a system with Intel > Core i7-8750H. Specific error I get: > > [user@dom0 tsx]$ ./test-tsx > TSX tests > Got 16 CPUs > Testing MSR_TSX_FORCE_ABORT consistency > CPU0 val 0 > Testing MSR_TSX_CTRL consistency > Testing MSR_MCU_OPT_CTRL consistency > CPU0 val 0 > Testing RTM behaviour > Got #UD > Host reports RTM, but appears unavailable
Hmm - I should make this failure report more obviously distinguishable from the general logging. This is reporting a consistency-check failure, with a mismatch between actual-behaviour and what's in CPUID (host policy in practice). This is CoffeeLake, and was one of the CPUs which had TSX taken out, but something looks wonky. > When I try it on a newer system (11th gen) then it works fine (exit code > 0, just "Got #UD", no "Host reports RTM, but appears unavailable" line). RocketLake was after the decision to remove TSX from the client line, so will either genuinely not have the silicon, or it should be properly fused out. Anyway, back to CoffeeLake. The Raw policy shows rtm-always-abort and tsx-force-abort. Test-tsx says the value in MSR_TSX_FORCE_ABORT is 0, but that shouldn't be the case seeing as the RTM/HLE bits are hidden in real CPUID, but the CPUID_HIDE bit is clear. We do intentionally force RTM_ALWAYS_ABORT in some cases, because it self-hides in some cases. I wonder if we've got bug in that path. >From the state in Raw, we then synthesise HLE/RTM in the Host policy because MSR_TSX_FORCE_ABORT only exists on TSX-capable systems. However, if XBEGIN is really #UD-ing, we can't offer it as an opt-in to guests. Let me see about putting some debugging together. ~Andrew
