On Fri, 04 Jun 2021 16:50:20 +0100,
Sean Christopherson [off-list ref] wrote:

+Will and Marc

On Fri, Jun 04, 2021, Matthew Wilcox wrote:

quoted

I'm a bit confused about what PageTransCompoundMap() is supposed to do.
What it actually does is check that the specific page (which may or
may not be a head page) is not mapped by a PTE.  I don't understand why
you'd care how some (other?) process does or does not have it mapped.
What I _think_ you want to know is "Can I map this page with a PMD entry
in the guest".  And the answer to that is simply:

bool kvm_is_transparent_hugepage(kvm_pfn_t pfn)
{
	struct page *head = compound_head(pfn_to_page(pfn));
	return compound_order(head) >= HPAGE_PMD_ORDER;
}

but maybe there's some reason you don't want to map hugetlbfs or other
sufficiently large compound pages with PMDs?

Looking at the one caller of kvm_is_transparent_hugepage(), I'd be
tempted to inline the above into transparent_hugepage_adjust()
and call get_page() directly instead of indirecting through
kvm_get_pfn().

arm64 is the only remaining user of kvm_is_transparent_hugepage().

x86 purged its usage a while back, and instead looks at the host
PTEs via lookup_address_in_mm() to get the current mapping level.
The motivation was to consolidate the hugepage logic for THP,
HugeTLBFS, and DAX, and to naturally support both 2mb and 1gb for
all flavors of hugepages.

Could arm64 do something similar and kill off
kvm_is_transparent_hugepage() entirely?

Yup, we should be able to do that, although we get the additional fun
of caused by having 3 different page sizes. I'll have a go at it next
week.

Thanks for the heads up,

	M.

-- 
Without deviation from the norm, progress is not possible.