Re: [PATCH v9 3/6] KVM: arm64: Block cacheable PFNMAP mapping

[Ankit Agrawal <ankita@nvidia.com>]

> Sorry for the drive-by comment, but I was looking at this old series from
> Paolo (look at the cover letter and patch 5):
>
> https://lore.kernel.org/r/20250109133817.314401-1-pbonzini@redhat.com
>
> in which he points out that the arm64 get_vma_page_shift() function
> incorrectly assumes that a VM_PFNMAP VMA is physically contiguous, which
> may not be the case if a driver calls remap_pfn_range() to mess around
> with mappings within the VMA. I think that implies that the optimisation
> in 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for host device
> MMIO") is unsound.

Hm yeah, that does seem problematic. Perhaps we need a new
vma flag that could help the driver communicate to the KVM that the
mapping is contiguous and it can go ahead with the optimization?
E.g. something similar to VM_ALLOW_ANY_UNCACHED.

> But it got me thinking -- given that remap_pfn_range() also takes a 'prot'
> argument, how do we ensure that this is reflected in the guest? It feels
> a bit dodgy to rely on drivers always passing 'vma->vm_page_prot'.
>
> Will

The driver use the vm_page_prot sent through the VMM VMA and may
update some flags. Is your question that if we can trust the driver doing
the right thing and properly map through remap_pfn_range so as to not
conflict with VMM (vma->vm_page_prot)?