On Mon, Feb 01, 2021, Paolo Bonzini wrote: > On 29/01/21 17:58, Sean Christopherson wrote: > > On Fri, Jan 29, 2021, Paolo Bonzini wrote: > > > */ > > > if (!boot_cpu_has(X86_FEATURE_RTM)) > > > - data &= ~(ARCH_CAP_TAA_NO | ARCH_CAP_TSX_CTRL_MSR); > > > + data &= ~ARCH_CAP_TAA_NO; > > > > Hmm, simply clearing TSX_CTRL will only preserve the host value. Since > > ARCH_CAPABILITIES is unconditionally emulated by KVM, wouldn't it make > > sense to > > unconditionally expose TSX_CTRL as well, as opposed to exposing it only if > > it's > > supported in the host? I.e. allow migrating a TSX-disabled guest to a host > > without TSX. Or am I misunderstanding how TSX_CTRL is checked/used? > > I'm a bit wary of having a combination (MDS_NO=0, TSX_CTRL=1) that does not > exist on bare metal. There are other cases where such combinations can > happen, especially with the Spectre and SSBD mitigations (for example due to > AMD CPUID bits for Intel processors), but at least those are just > redundancies in the CPUID bits and it's more likely that the guest does > something sensible with them.
Gotcha. The vulnerability combos and all the double and triple negatives make my head spin. Thanks!
