On Tue, Nov 02, 2021, Vipin Sharma wrote: > Sorry for the late reply. > > On Thu, Oct 14, 2021 at 10:05 AM Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > > > On Thu, Oct 14, 2021 at 9:54 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > Oh, yeah, definitely. I missed that SVM's invpcid_interception() has the same > > > open-coded check. > > > > > > Alternatively, could we handle the invalid type in the main switch statement? I > > > don't see anything in the SDM or APM that architecturally _requires_ the type be > > > checked before reading the INVPCID descriptor. Hardware may operate that way, > > > but that's uArch specific behavior unless there's explicit documentation. > > > > Right. INVVPID and INVEPT are explicitly documented to check the type > > first, but INVPCID is not. > > It seems to me that I can move type > 3 check to kvm_handle_invpcid() > switch statement. I can replace BUG() in that switch statement with > kvm_inject_gp for the default case, I won't even need INVPCID_TYPE_MAX > in this case. Yep. > If you are fine with this approach then I will send out a patch where > invalid type is handled in kvm_handle_invpcid() switch statement. This has my vote.
