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

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

[Sean Christopherson]

On Mon, Apr 27, 2026, Peter Fang wrote:
> On Fri, Apr 24, 2026 at 11:27:03AM +0100, David Woodhouse wrote:
> > 
> > Fred is already removing all the usage of kvm_vcpu_map() in nested VMX¹
> > and nested SVM probably wants the same treatment. And the PowerPC one
> > looks like it could just as easily operate on the userspace address? 
> > 
> > Could we just kill kvm_vcpu_map() completely?

Yeah, that's probably for the best in the long run.

> 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.

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

[Peter Fang]

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.

Makes sense to me. Thanks for the review Sean!