Re: [PATCH v3 2/2] KVM: Move INVPCID type check from vmx and svm to the common kvm_handle_invpcid()

[Sean Christopherson <seanjc@google.com>]

On Wed, Nov 03, 2021, Vipin Sharma wrote:
> On Wed, Nov 3, 2021 at 4:20 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Wed, Nov 03, 2021, Vipin Sharma wrote:
> > > Handle #GP on INVPCID due to an invalid type in the common switch
> > > statement instead of relying on the callers (VMX and SVM) to manually
> > > validate the type.
> > >
> > > Unlike INVVPID and INVEPT, INVPCID is not explicitly documented to check
> > > the type before reading the operand from memory, so deferring the
> > > type validity check until after that point is architecturally allowed.
> > >
> > > Signed-off-by: Vipin Sharma <vipinsh@google.com>
> > > ---
> >
> > For future reference, a R-b that comes with qualifiers can be carried so long as
> > the issues raised by the reviewer are addressed.  Obviously it can be somewhat
> > subjective, but common sense usually goes a long ways, and most reviewers won't
> > be too grumpy about mistakes so long as you had good intentions and remedy any
> > mistakes.  And if you're in doubt, you can always add a blurb in the cover letter
> > or ignored part of the patch to explicitly confirm that it was ok to add the tag,
> > e.g. "Sean, I added your Reviewed-by in patch 02 after fixing the changelog, let
> > me know if that's not what you intended".
> >
> > Thanks!
> >
> > Reviewed-by: Sean Christopherson <seanjc@google.com>
> 
> I was not sure if I can add R-b as it was only for the code and not
> changelog. Good to know that I can ask such things in the cover letter
> or the ignored part of the patch.

Ah, that's my bad, that was indeed a very confusing way to phrase my contingent
review.