On Tue, Jul 07, 2020 at 10:17:14AM +0200, Paolo Bonzini wrote: > On 07/07/20 10:14, Sean Christopherson wrote: > >>> One oddity with this whole thing is that by passing through the MSR, KVM > >>> is > >>> allowing the guest to write bits it doesn't know about, which is > >>> definitely > >>> not normal. It also means the guest could write bits that the host VMM > >>> can't. > >> That's true. However, the main purpose of the kvm_spec_ctrl_valid_bits > >> check is to ensure that host-initiated writes are valid; this way, you > >> don't get a #GP on the next vmentry's WRMSR to MSR_IA32_SPEC_CTRL. > >> Checking the guest CPUID bit is not even necessary. > > Right, what I'm saying is that rather than try and decipher specs to > > determine what bits are supported, just throw the value at hardware and > > go from there. That's effectively what we end up doing for the guest writes > > anyways. > > Yes, it would prevent the #GP. > > > Actually, the current behavior will break migration if there are ever legal > > bits that KVM doesn't recognize, e.g. guest writes a value that KVM doesn't > > allow and then migration fails when the destination tries to stuff the value > > into KVM. > > Yes, unfortunately migration would also be broken if the target (and the > guest CPUID) is an older CPU. But that's not something we can fix > without trapping all writes which would be unacceptably slow.
Ah, true, the guest would need to be setting bits that weren't enumerated to it.
