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?
