Re: [PATCH v2 3/3] KVM: Take gpa_t in kvm_vcpu_map[_readonly]()

[Sean Christopherson <seanjc@google.com>]

On Wed, Apr 22, 2026, Yosry Ahmed wrote:
> On Wed, Apr 22, 2026 at 1:34 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Wed, Apr 22, 2026, Yosry Ahmed wrote:
> > > > > Perhaps we just need to rename the functions (e.g.
> > > > > kvm_vcpu_map_page()), or more intrusively pass in a size and do bounds
> > > > > checking.
> > > >
> > > > Definitely the latter.  Or both I guess, but probably just the latter.
> > >
> > > I think both. I think renaming to kvm_vcpu_map_page() (and similar for
> > > others) would further clarify things, especially with the introduction
> > > of kvm_vcpu_map_ptr() below.
> >
> > I don't like "page" it's too easy to incorrectly assume "page" means "struct page".
> > There are KVM APIs that do use "page" generically, e.g. kvm_read_guest_page(),
> > but for this particular case I'd like to stay away from "page; there's a _lot_
> > of ugly history around mapping "struct page" vs. "other" memory in KVM.
> 
> Maybe kvm_vcpu_map_guest_page()? or if you reaaaally wanna be clear
> about it kvm_vcpu_map_page_sized_chunk_of_guest_memory() :P

And rename all the extensions to .java while we're at it.

I can live with kvm_vcpu_map_guest_page().  kvm_vcpu_map_ptr() becomes a bit
odd, but kvm_vcpu_map_guest_ptr() is even worse.