[PATCH v2 3/3] KVM: Take gpa_t in kvm_vcpu_map[_readonly]()
Sean Christopherson
seanjc at google.com
Thu Apr 23 08:17:27 AEST 2026
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.
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.
More information about the Linuxppc-dev
mailing list