Refusing to let userspace set IA32_ARCH_CAPABILITIES.RSBA is a problem for us. Following Intel's guidance, our userspace sets this bit to indicate that a VM might be scheduled to run on a vulnerable processor. On Fri, Mar 8, 2019 at 6:29 PM Xiaoyao Li <xiaoyao.li@xxxxxxxxxxxxxxx> wrote: > > 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. >
