summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/python_version.py
diff options
context:
space:
mode:
authorMostafa Saleh <smostafa@google.com>2026-09-29 20:02:09 +0000
committerOliver Upton <oupton@kernel.org>2026-10-01 09:27:26 -0700
commit71cc2c67fb8f8d5aa8154eb482e9846d2214f11b (patch)
treea5016ddf8af58fcde7acdb8f7e2f56a3c0a6d558 /tools/lib/python/kdoc/python_version.py
parentafb4334fb52c7b416bbc9c4b166f6806509f734b (diff)
downloadlinux-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