Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <61067e86f0a52314cb6aceeaef5c73846d142a42.camel@redhat.com>
Subject: Re: [PATCH] KVM: nSVM: Pull CS.Base from actual VMCB12 for soft
 int/ex re-injection
From:   Maxim Levitsky <mlevitsk@redhat.com>
To:     Sean Christopherson <seanjc@google.com>,
        "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc:     Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu, 21 Jul 2022 14:51:30 +0300
In-Reply-To: <Yth00gK0DWjukLgq@google.com>
References: <4caa0f67589ae3c22c311ee0e6139496902f2edc.1658159083.git.maciej.szmigiero@oracle.com>
         <7458497a8694ba0fbabee28eabf557e6e4406fbe.camel@redhat.com>
         <d311c92a-d753-3584-d662-7d82b2fc1e50@maciej.szmigiero.name>
         <Yth00gK0DWjukLgq@google.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 2022-07-20 at 21:34 +0000, Sean Christopherson wrote:
> On Wed, Jul 20, 2022, Maciej S. Szmigiero wrote:
> > On 20.07.2022 10:43, Maxim Levitsky wrote:
> > > On Mon, 2022-07-18 at 17:47 +0200, Maciej S. Szmigiero wrote:
> > > > Fixes: 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction")
> > > > Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
> > > > ---
> > > >   arch/x86/kvm/svm/nested.c | 9 +++++----
> > > >   1 file changed, 5 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> > > > index adf4120b05d90..23252ab821941 100644
> > > > --- a/arch/x86/kvm/svm/nested.c
> > > > +++ b/arch/x86/kvm/svm/nested.c
> > > > @@ -639,7 +639,8 @@ static bool is_evtinj_nmi(u32 evtinj)
> > > >   }
> > > >   static void nested_vmcb02_prepare_control(struct vcpu_svm *svm,
> > > > -                                         unsigned long vmcb12_rip)
> > > > +                                         unsigned long vmcb12_rip,
> > > > +                                         unsigned long vmcb12_csbase)
> > > 
> > > Honestly I don't like that nested_vmcb02_prepare_control starts to grow its parameter list,
> > > because it kind of defeats the purpose of vmcb12 cache we added back then.
> > > 
> > > I think that it is better to add csbase/rip to vmcb_save_area_cached,
> > > but I am not 100% sure. What do you think?
> > 
> > This function has only 3 parameters now, so they fit well into registers
> > without taking any extra memory (even assuming it won't get inlined).
> > 
> > If in the future more parameters need to be added to this function
> > (which may or may not happen) then they all can be moved to, for example,
> > vmcb_ctrl_area_cached.
> 
> I don't think Maxim is concerned about the size, rather that we have a dedicated
> struct for snapshotting select save state and aren't using it.

Yes my thoughts exactly. The thing is that passing these values as parameters to this function
also works like a cache, but not going through the cache that we already have
for this purpose.

Anyway for now let it be, but we might need to rethink it in the future.

Best regards,
	Maxim Levitsky

> 
> IIRC, I deliberately avoided using the "cache" because the main/original purpose
> of the cache is to avoid TOCTOU issues.  And because RIP and CS.base aren't checked,
> there's no need to throw them in the cache.