diff options
| author | Mostafa Saleh <smostafa@google.com> | 2026-09-29 20:02:09 +0000 |
|---|---|---|
| committer | Oliver Upton <oupton@kernel.org> | 2026-10-01 09:27:26 -0700 |
| commit | 71cc2c67fb8f8d5aa8154eb482e9846d2214f11b (patch) | |
| tree | a5016ddf8af58fcde7acdb8f7e2f56a3c0a6d558 /tools/lib/python/kdoc/python_version.py | |
| parent | afb4334fb52c7b416bbc9c4b166f6806509f734b (diff) | |
| download | linux-next-71cc2c67fb8f8d5aa8154eb482e9846d2214f11b.tar.gz linux-next-71cc2c67fb8f8d5aa8154eb482e9846d2214f11b.zip | |
KVM: arm64: Use stage-1 leaf size for VM_PFNMAP
When commit 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for
host device MMIO") added VM_PFNMAP support to get_vma_page_shift(),
stage-1 page tables did not support huge PFNMAP (as in VFIO-PCI
vfio_pci_mmap_huge_fault()) and transparent_hugepage_adjust() was
unsafe for MMIO as it dereferenced struct page.
Since commit 6011cf68c885 ("KVM: arm64: Walk userspace page tables to
compute the THP mapping size"), transparent_hugepage_adjust() instead
walks the host stage-1 page tables via get_user_mapping_size() without
touching struct page. Meanwhile, commit 3e509c9b03f9 ("mm/arm64:
support large pfn mappings") enabled stage-1 huge PFNMAP.
So. we can drop the VMA-based VM_PFNMAP size calculation in
get_vma_page_shift() and let transparent_hugepage_adjust() derive
the stage-2 mapping size directly from the populated stage-1 leaf
for non-cacheable mappings as well.
Assisted-by: LLM
Cc: stable@vger.kernel.org
Fixes: 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for host device MMIO")
Reviewed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Oliver Upton <oupton@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions
