[PATCH v2] KVM: arm64: Try PMD block mappings if PUD mappings are not supported

Punit Agrawal punit1.agrawal at toshiba.co.jp
Tue Sep 15 04:23:59 EDT 2020

Hi Alex,

Alexandru Elisei <alexandru.elisei at arm.com> writes:

> Hi Punit,
> Thank you for having a look!
> On 9/11/20 9:34 AM, Punit Agrawal wrote:
>> Hi Alexandru,
>> Alexandru Elisei <alexandru.elisei at arm.com> writes:
>>> When userspace uses hugetlbfs for the VM memory, user_mem_abort() tries to
>>> use the same block size to map the faulting IPA in stage 2. If stage 2
>>> cannot the same block mapping because the block size doesn't fit in the
>>> memslot or the memslot is not properly aligned, user_mem_abort() will fall
>>> back to a page mapping, regardless of the block size. We can do better for
>>> PUD backed hugetlbfs by checking if a PMD block mapping is supported before
>>> deciding to use a page.
>> I think this was discussed in the past.
>> I have a vague recollection of there being a problem if the user and
>> stage 2 mappings go out of sync - can't recall the exact details.
> I'm not sure what you mean by the two tables going out of sync. I'm looking at
> Documentation/vm/unevictable-lru.rst and this is what it says regarding hugetlbfs:
> "VMAs mapping hugetlbfs page are already effectively pinned into memory.  We
> neither need nor want to mlock() these pages.  However, to preserve the prior
> behavior of mlock() - before the unevictable/mlock changes - mlock_fixup() will
> call make_pages_present() in the hugetlbfs VMA range to allocate the huge pages
> and populate the ptes."
> Please correct me if I'm wrong, but my interpretation is that once a hugetlbfs
> page has been mapped in a process' address space, the only way to unmap it is via
> munmap. If that's the case, the KVM mmu notifier should take care of unmapping
> from stage 2 the entire memory range addressed by the hugetlbfs pages,
> right?

You're right - I managed to confuse myself. Thinking about it with a bit
more context, I don't see a problem with what the patch is doing.

Apologies for the noise.

>> Putting it out there in case anybody else on the thread can recall the
>> details of the previous discussion (offlist).
>> Though things may have changed and if it passes testing - then maybe I
>> am mis-remembering. I'll take a closer look at the patch and shout out
>> if I notice anything.
> The test I ran was to boot a VM and run ltp (with printk's sprinkled in the host
> kernel to see what page size and where it gets mapped/unmapped at stage 2). Do you
> mind recommending other tests that I might run?

You may want to put the changes through VM save / restore and / or live
migration. It should help catch any issues with transitioning from
hugepages to regular pages.

Hope that helps.



More information about the linux-arm-kernel mailing list