On 5/20/25 20:24, Stefano Stabellini wrote: > Hi Juergen and all, > > We have an issue where QEMU is mapping foreign pages as usual and > passing them to a driver in Linux (amdxdna). The driver in Linux calls > pin_user_pages_fast() on these pages, and it returns -EFAULT. Stack > trace appended below.
Is the QEMU virtual device that does this upstreamed? > This is Dom0 PVH. We disabled CONFIG_XEN_UNPOPULATED_ALLOC and > CONFIG_XEN_BALLOON_MEMORY_HOTPLUG attemping to make things better but it > did not solved the issue. We tried changing pin_user_pages_fast() to > pin_user_pages(), still -EFAULT. check_vma_flags returns -EFAULT because > of the (VM_IO | VM_PFNMAP) check. > > We tried removing (VM_IO | VM_PFNMAP) from privcmd_mmap and > xen_xlate_remap_gfn_array based on the idea that the underlying pages > are normal memory once CONFIG_XEN_UNPOPULATED_ALLOC and > CONFIG_XEN_BALLOON_MEMORY_HOTPLUG are disabled. > > In this case, vm_normal_page takes the if > (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) path, none of the checks work, > so it calls print_bad_pte and it breaks. > > As another attempt, we tried removing pte_mkspecial from > xlate_mmu.c:remap_pte_fn and remap_pfn_fn, based again on the same idea > that the underlying pages should not be "special". Now it went further > but it broke at unmap_vmas time on a reference counting error. Specifically, > we get "non-zero mapcount" on the callchain from unmap_vmas: > > [31789.440433] BUG: Bad page map in process qemu-system-x86 > pte:800000018f8a9027 pmd:13c29a067 > [31789.440459] page:000000008316c487 refcount:0 mapcount:-1 > mapping:0000000000000000 index:0x0 pfn:0x18f8a9 > [31789.440461] flags: > 0x17ffffc0000214(referenced|dirty|workingset|node=0|zone=2|lastcpupid=0x1fffff) > [31789.440463] page_type: 0xfffffffe() > [31789.440465] raw: 0017ffffc0000214 dead000000000100 dead000000000122 > 0000000000000000 > [31789.440467] raw: 0000000000000000 0000000000000000 00000000fffffffe > 0000000000000000 > [31789.440468] page dumped because: bad pte > [31789.440469] addr:0000780c1213a000 vm_flags:0c0600fb > anon_vma:0000000000000000 mapping:ffff888185672418 index:3a > [31789.440498] file:privcmd fault:privcmd_fault [xen_privcmd] > mmap:privcmd_mmap [xen_privcmd] read_folio:0x0 > > So, it would seem that we need to keep treating foreign mapping pages as > special (pte_mkspecial and also VM_IO | VM_PFNMAP) but if we do that > pin_user_pages() fails. > > Do you have any ideas how to get pin_user_pages() to work with foreign > mappings from userspace?I Does the privcmd driver try to free the pages while amdxdna is still using them? privcmd might be assuming that the pages are freed once the unmap ioctl is called from userspace and the pages are unmapped from userspace memory. That isn't true if the pages are pinned by another driver. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
