On 25/09/19 20:09, Sean Christopherson wrote: > We're trying to sort out the trainwreck, but there's an additional wrinkle > that I'd like your input on. That's not exactly a wrinkle... > - Remove KVM loading of MSR_TEST_CTRL, i.e. KVM *never* writes the CPU's > actual MSR_TEST_CTRL. KVM still emulates MSR_TEST_CTRL so that the > guest can do WRMSR and handle its own #AC faults, but KVM doesn't > change the value in hardware. > > * Allowing guest to enable split-lock detection can induce #AC on > the host after it has been explicitly turned off, e.g. the sibling > hyperthread hits an #AC in the host kernel, or worse, causes a > different process in the host to SIGBUS. > > * Allowing guest to disable split-lock detection opens up the host > to DoS attacks. > > - KVM advertises split-lock detection to guest/userspace if and only if > split_lock_detect_disabled is zero. > > - Add a pr_warn_once() in KVM that triggers if split locks are disabled > after support has been advertised to a guest. > > Does this sound sane? Not really, unfortunately. Just never advertise split-lock detection to guests. If the host has enabled split-lock detection, trap #AC and forward it to the host handler---which would disable split lock detection globally and reenter the guest. Paolo