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.
