Given that userspace is responsible for setting up reasonable CPUID values, why do we have special handling for INVPCID? Specifically, why clear INVPCID from the guest CPUID when the guest CPUID doesn't enumerate support for PCID? Yes, it's a strange combination, but why impose this constraint in the kernel, especially when we don't impose any similar constraints? For example, we allow AVX-512 without XSAVE, and that combination makes even less sense than INVPCID without PCID. On Mon, Apr 30, 2018 at 6:21 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 27/04/2018 02:57, Junaid Shahid wrote: >> On 04/26/2018 04:16 PM, Jim Mattson wrote: >>> On Thu, Apr 26, 2018 at 3:43 PM, Junaid Shahid <junaids@xxxxxxxxxx> >>> wrote: >>>> When INVPCID is not supported, KVM should clear the INVPCID bit >>>> from the guest CPUID. >>> This seems to be the only guest CPUID bit that's verified in this >>> way. That seems...odd. Why enforce this one constraint? >> >> Hmm. I wonder if the other bits are not validated intentionally, >> perhaps to facilitate user-mode emulation? If that is the case, then >> yes, we don't need to validate the INVPCID bit either. > > They are not validated mostly because it's pointless. Userspace is > supposed to validate them against KVM_GET_SUPPORTED_CPUID, if it doesn't > it's garbage-in garbage-out. INVPCID and others have some special > casing because they require toggling some execution controls, but that's > where those needs end. > > Thanks, > > Paolo
