On Tue, Jul 25, 2023, Wei W Wang wrote:
> On Wednesday, July 19, 2023 7:45 AM, Sean Christopherson wrote:
> > +int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> > + gfn_t gfn, kvm_pfn_t *pfn, int *max_order) {
> > + pgoff_t index = gfn - slot->base_gfn + slot->gmem.pgoff;
> > + struct kvm_gmem *gmem;
> > + struct folio *folio;
> > + struct page *page;
> > + struct file *file;
> > +
> > + file = kvm_gmem_get_file(slot);
> > + if (!file)
> > + return -EFAULT;
> > +
> > + gmem = file->private_data;
> > +
> > + if (WARN_ON_ONCE(xa_load(&gmem->bindings, index) != slot)) {
> > + fput(file);
> > + return -EIO;
> > + }
> > +
> > + folio = kvm_gmem_get_folio(file_inode(file), index);
> > + if (!folio) {
> > + fput(file);
> > + return -ENOMEM;
> > + }
> > +
> > + page = folio_file_page(folio, index);
> > +
> > + *pfn = page_to_pfn(page);
> > + *max_order = compound_order(compound_head(page));
>
> Maybe better to check if caller provided a buffer to get the max_order:
> if (max_order)
> *max_order = compound_order(compound_head(page));
>
> This is what the previous version did (restrictedmem_get_page),
> so that callers who only want to get a pfn don't need to define
> an unused "order" param.
My preference would be to require @max_order. I can kinda sorta see why a generic
implementation (restrictedmem) would make the param optional, but with gmem being
KVM-internal I think it makes sense to require the param. Even if pKVM doesn't
_currently_ need/want the order of the backing allocation, presumably that's because
hugepage support is still on the TODO list, not because pKVM fundamentally doesn't
need to know the order of the backing allocation.
