[PATCH v6 4/5] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags
Sean Christopherson
seanjc at google.com
Fri Jun 6 11:14:38 PDT 2025
On Sat, May 24, 2025, ankita at nvidia.com wrote:
> @@ -1636,9 +1637,19 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>
> vfio_allow_any_uc = vma->vm_flags & VM_ALLOW_ANY_UNCACHED;
>
> - if ((vma->vm_flags & VM_PFNMAP) &&
> - !mapping_type_noncacheable(vma->vm_page_prot))
> - return -EINVAL;
> + if (vma->vm_flags & VM_PFNMAP) {
> + /* Reject COW VM_PFNMAP */
> + if (is_cow_mapping(vma->vm_flags))
> + return -EINVAL;
> +
> + /*
> + * If the VM_PFNMAP is set in VMA flags, do a KVM sanity
> + * check to see if pgprot mapping type is MT_NORMAL and a
> + * safely cacheable device memory.
> + */
> + if (!mapping_type_noncacheable(vma->vm_page_prot))
> + cacheable_devmem = true;
> + }
>
> /* Don't use the VMA after the unlock -- it may have vanished */
> vma = NULL;
> @@ -1671,10 +1682,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> * via __kvm_faultin_pfn(), vma_pagesize is set to PAGE_SIZE
> * and must not be upgraded.
> *
> - * In both cases, we don't let transparent_hugepage_adjust()
> + * Do not set device as the device memory is cacheable. Note
> + * that such mapping is safe as the KVM S2 will have the same
> + * Normal memory type as the VMA has in the S1.
> * change things at the last minute.
> */
> - device = true;
> + if (!cacheable_devmem)
> + device = true;
I doubt this is correct. "device" is used for more than just the memtype. E.g.
hugepage adjustments, MTE, etc. all consult "device". I.e. don't conflate device
with VM_PFNMAP.
More information about the linux-arm-kernel
mailing list