Re: [PATCH 3/4] KVM: x86: SVM: use vmcb01 in avic_init_vmcb

[Sean Christopherson <seanjc@google.com>]

On Tue, Mar 01, 2022, Maxim Levitsky wrote:
> On Tue, 2022-03-01 at 16:21 +0000, Sean Christopherson wrote:
> > Just "KVM: SVM:" for the shortlog, please.
> > 
> > On Tue, Mar 01, 2022, Maxim Levitsky wrote:
> > > Out of precation use vmcb01 when enabling host AVIC.
> > > No functional change intended.
> > > 
> > > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> > > ---
> > >  arch/x86/kvm/svm/avic.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
> > > index e23159f3a62ba..9656e192c646b 100644
> > > --- a/arch/x86/kvm/svm/avic.c
> > > +++ b/arch/x86/kvm/svm/avic.c
> > > @@ -167,7 +167,7 @@ int avic_vm_init(struct kvm *kvm)
> > >  
> > >  void avic_init_vmcb(struct vcpu_svm *svm)
> > >  {
> > > -	struct vmcb *vmcb = svm->vmcb;
> > > +	struct vmcb *vmcb = svm->vmcb01.ptr;
> > 
> > I don't like this change.  It's not bad code, but it'll be confusing because it
> > implies that it's legal for svm->vmcb to be something other than svm->vmcb01.ptr
> > when this is called.
> 
> Honestly I don't see how you had reached this conclusion.

There's exactly one caller, init_vmcb(), and that caller doesn't assert that the
current VMCB is vmcb01, nor does it unconditionally use vmcb01.  Adding code here
without an assert implies that init_vmcb() may be called with vmcb02 active,
otherwise why diverge from its one caller?

> I just think that code that always works on vmcb01
> should use it, even if it happens that vmcb == vmcb01.

I'm not disagreeing, I'm saying that the rule you want to enforce also applies
to init_vmcb(), so rather than introduce inconsistent code in all the leafs, fix
the problem at the root.  I've no objection to adding a WARN in the AVIC code (though
at that point I'd vote to just pass in @vmcb), I'm objecting to "silently" diverging.