Re: Linux pin_user_pages_fast fails on Xen

[Stefano Stabellini <stefano.stabellini@xxxxxxx>]

On Wed, 14 Sep 2022, Jan Beulich wrote:
> On 14.09.2022 01:31, Stefano Stabellini wrote:
> > The problem is that drivers/xen/privcmd.c:privcmd_mmap sets VM_IO |
> > VM_PFNMAP, and either flag would cause check_vma_flags to return
> > -EFAULT.
> > 
> > Do you know if it works if you remove VM_IO | VM_PFNMAP from
> > privcmd_mmap?
> 
> My Linux MM knowledge is certainly rusty, but I don't think this can
> work, at the very least not without further changes elsewhere.

The definition of VM_PFNMAP is:

    Page-ranges managed without "struct page", just pure PFN

So it made perfect sense to use VM_PFNMAP back in the day when we were
using address ranges without "struct page" for foreign mappings.


However, nowadays Linux drivers typically call
xen_alloc_unpopulated_pages to get local pages to be used for foreign
mappings. xen_alloc_unpopulated_pages should work for both PV and
autotranslated guests. So the local pages should have a regular "struct
page" backing them.

I noticed that privcmd calls
alloc_empty_pages->xen_alloc_unpopulated_pages only for autotranslated
guests. Do you guys think it is intentional? In theory,
xen_alloc_unpopulated_pages should work for PV guests too.

After that, privcmd calls xen_remap_domain_gfn_array, which calls
xen_xlate_remap_gfn_array or xen_remap_pfn depending on
PV or autotranslated.

But then I can see the following at the top of xlate_remap_gfn_array:

        /* Kept here for the purpose of making sure code doesn't break
           x86 PVOPS */
        BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));

and a similar one in arch/x86/xen/mmu_pv.c:xen_remap_pfn:

        BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));


Given that the pages passed to xen_xlate_remap_gfn_array and
xen_remap_pfn could have been allocated with
xen_alloc_unpopulated_pages, why the BUG_ON?

Is this just legacy? In the sense that the following could work?

- privcmd calls xen_alloc_unpopulated_pages for both PV & autotranslated
- no setting VM_PFNMAP | VM_IO
- no BUG_ON in xlate_remap_gfn_array
- no BUG_ON in xen_remap_pfn

Am I missing something?


> I did look some at the specific use by the TEE subsystem, and it looks
> to me as if their "shared memory" machinery simply isn't meant to be
> used with non-local memory.

Any more info?