On Wed, May 25, 2022 at 5:45 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Wed, May 25, 2022, Jim Mattson wrote: > > On Wed, May 25, 2022 at 2:04 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > > > Add an off-by-default module param, reject_inconsistent_vmcs_config, to > > > allow rejecting the load of kvm_intel if an inconsistent VMCS config is > > > detected. Continuing on with an inconsistent, degraded config is > > > undesirable when the CPU is expected to support a given set of features, > > > e.g. can result in a misconfigured VM if userspace doesn't cross-check > > > KVM_GET_SUPPORTED_CPUID, and/or can result in poor performance due to > > > lack of fast MSR switching. > > > > > > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx> > > > --- > > There are several inconsistent VMCS configs that are not rejected here > > (e.g. "enable XSAVES/XRSTORS" on a CPU that doesn't support XSAVES). > > Do you plan to include more checks in the future, or should this be, > > "reject_some_inconsistent_vmcs_configs"? :-) > > I have no plan, it was purely a reaction to continuing on with a known bad entry/exit > pair handling being awful. I hesitated to even apply it to the EPT/VPID stuff, but > again it seemed silly to detect an inconsistency and do nothing about it. > > I'm not opposed to adding more checks, though there is definitely a point of > diminishing returns. I'm just picking the really low hanging fruit :-) The usual KVM approach to a misconfigured guest is to let userspace shoot itself in the foot, as long as it doesn't put the host at risk. This change seems to run counter to that.
