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

Hi Alex,

Alexandru Elisei [off-list ref] writes:

Hi Punit,

Thank you for having a look!

On 9/11/20 9:34 AM, Punit Agrawal wrote:

quoted

Hi Alexandru,

Alexandru Elisei [off-list ref] writes:

quoted

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.

quoted

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.

Thanks,
Punit

[...]


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel