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

Yosry Ahmed yosry at kernel.org
Thu Apr 23 08:19:04 AEST 2026


On Wed, Apr 22, 2026 at 3:17 PM Sean Christopherson <seanjc at google.com> wrote:
>
> On Wed, Apr 22, 2026, Yosry Ahmed wrote:
> > On Wed, Apr 22, 2026 at 1:34 PM Sean Christopherson <seanjc at 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.

Lovely.

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

FWIW I still think kvm_vcpu_map_page() and kvm_vcpu_map_ptr() are the
best options. kvm_vcpu_map_guest_page() and kvm_vcpu_map_ptr() are
also fine imo.


More information about the Linuxppc-dev mailing list