On Fri, 2019-03-08 at 09:41 -0800, Sean Christopherson wrote: > On Fri, Mar 08, 2019 at 09:29:15AM -0800, Jim Mattson wrote: > > On Thu, Mar 7, 2019 at 3:43 PM Sean Christopherson > > <sean.j.christopherson@xxxxxxxxx> wrote: > > > > > > For all intents and purposes, MSR_IA32_ARCH_CAPABILITIES is a CPUID > > > feature leaf. Now that it is emulated, give it the same treatment we > > > give CPUID leafs with a mixture of emulated and hardware-only features > > > and reject attempts by host userspace to expose features to the guest > > > that are not supported by KVM, i.e. are not supported in hardware and > > > are not emulated by KVM. > > > > I didn't think we rejected attempts by host userspace to expose CPUID > > features to the guest that aren't supported by kvm. I know we do so > > for VMX capability MSRs, but is this overkill for this particular MSR? > > Argh, you're right, I got my brain twisted around again, I keep thinking > that masking bits in KVM_GET_CPUID2 means KVM prevents setting them via > KVM_SET_CPUID2. I think masking bits in KVM_GET_CPUID2 only means KVM doesn't support the feature for guest, but not prevents setting them via KVM_SET_CPUID2. Because userspace may have the ability to emulate that feature.
