[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <rckoq7j5pbe7rkszw7d7kkcyjpjpmdwexyrlcw2hyf6cgzpohf@scxmalwv6buz>
Date: Wed, 10 Dec 2025 16:16:23 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Jim Mattson <jmattson@...gle.com>,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 11/13] KVM: nSVM: Simplify nested_svm_vmrun()
On Tue, Dec 09, 2025 at 11:09:26AM -0800, Sean Christopherson wrote:
> On Tue, Dec 09, 2025, Yosry Ahmed wrote:
> > On Tue, Dec 09, 2025 at 08:11:41AM -0800, Sean Christopherson wrote:
> > > On Mon, Nov 10, 2025, Yosry Ahmed wrote:
> > > > Call nested_svm_merge_msrpm() from enter_svm_guest_mode() if called from
> > > > the VMRUN path, instead of making the call in nested_svm_vmrun(). This
> > > > simplifies the flow of nested_svm_vmrun() and removes all jumps to
> > > > cleanup labels.
> > > >
> > > > Signed-off-by: Yosry Ahmed <yosry.ahmed@...ux.dev>
> > > > ---
> > > > arch/x86/kvm/svm/nested.c | 28 +++++++++++++---------------
> > > > 1 file changed, 13 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> > > > index a48668c36a191..89830380cebc5 100644
> > > > --- a/arch/x86/kvm/svm/nested.c
> > > > +++ b/arch/x86/kvm/svm/nested.c
> > > > @@ -1020,6 +1020,9 @@ int enter_svm_guest_mode(struct kvm_vcpu *vcpu, u64 vmcb12_gpa, bool from_vmrun)
> > > >
> > > > nested_svm_hv_update_vm_vp_ids(vcpu);
> > > >
> > > > + if (from_vmrun && !nested_svm_merge_msrpm(vcpu))
> > >
> > > This is silly, just do:
> >
> > Ack. Any objections to just dropping from_vmrun and moving
> > kvm_make_request(KVM_REQ_GET_NESTED_STATE_PAGES) to svm_leave_smm()? I
> > like the consistency of completely relying on from_vmrun or not at all
>
> Zero objections. When I was initially going through this, I actually thought you
> were _adding_ the flag and was going to yell at you :-)
Ugh from_vmrun is also plumbed into nested_svm_load_cr3() as
reload_pdptrs. Apparently we shouldn't do that in the call path from
svm_leave_smm()? Anyway, seems like it'll be non-trivial to detangle (at
least for me, I have 0 understanding of SMM), so I will leave it as-is.
Powered by blists - more mailing lists