[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALMp9eQTYY3NiP-3fZgnMn9-nGWTtx7aA3T0-tTvdfeZkhdNrA@mail.gmail.com>
Date: Wed, 25 May 2022 18:00:24 -0700
From: Jim Mattson <jmattson@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org,
Chenyi Qiang <chenyi.qiang@...el.com>,
Lei Wang <lei4.wang@...el.com>
Subject: Re: [PATCH 2/2] KVM: VMX: Add knob to allow rejecting kvm_intel on
inconsistent VMCS config
On Wed, May 25, 2022 at 5:45 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Wed, May 25, 2022, Jim Mattson wrote:
> > On Wed, May 25, 2022 at 2:04 PM Sean Christopherson <seanjc@...gle.com> 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@...gle.com>
> > > ---
> > 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.
Powered by blists - more mailing lists