Re: [PATCH v2 0/3] KVM: Fix and clean up kvm_vcpu_map[_readonly]() usages

[Sean Christopherson <seanjc@google.com>]

On Thu, May 07, 2026, Peter Fang wrote:
> On Mon, May 04, 2026 at 10:59:06AM -0700, Sean Christopherson wrote:
> > On Mon, Apr 27, 2026, Peter Fang wrote:
> > 
> > > Thanks David!
> > > 
> > > I think I'd need at least input from the maintainers on this but just by
> > > code inspection, the kvm_vcpu_map() usage in sev.c seems a bit tricky.
> > > Unmapping doesn't happen until right before switching to the guest, so
> > > this might fall into the "keep the mapping around for a longer time"
> > > category [1].
> > 
> > It definitely falls into that category.  But that code is also rather gross, i.e.
> > could use some cleanup no matter what, so I don't think it's a good argument for
> > keeping kvm_vcpu_map() around.
> > 
> > To avoid a bunch of pointless work and churn, let's hold off on hardening and/or
> > renaming kvm_vcpu_map() for now.  I'll take this v2 as-is; even though taking a
> > gpa instead of a gfn will conflict with the nVMX series, it's dead simple and a
> > worthwhile cleanup even if some of the conversions get discarded shortly after.

I had a change of heart after looking at the applied code, and after going through
Fred's gpc+nVMX series.  I don't want to have a discrepancy between kvm_vcpu_map()
and __kvm_vcpu_map(), even for a "short" amount of time, and I do think it makes
sense to pursue switching to gpcs for the nested code.  But, I also agree with the
changelog's statement that __kvm_vcpu_map() fundamentally operates on gfns, i.e. I
don't want to "fix" the discrepancy.

The other thing that swayed me is patch 2; I have a separate patch (amusingly
related to gpc stuff) to extra gpa_to_gfn (and others) into kvm_types.h, and so
I don't want to take patch 2 either.

Long story short, I'm going to grab only patch 1.