Re: [Xen-devel] DomU application crashes while mmap'ing device memory on x86_64

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

Thank you for explanation, now it is clear.

BTW, is PAGE_SHARED the right choice in my case

or should I use something else instead?

Thank you,
Oleksandr

On 11/30/2016 09:10 PM, Andrew Cooper wrote:
> On 30/11/16 19:00, Oleksandr Andrushchenko wrote:
> > I traced the problem down to vma->vm_page_prot which
> >
> > in my case is set as:
> >
> > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> >
> > This sets additional flags _PAGE_BIT_PSE/_PAGE_BIT_PAT +_PAGE_BIT_PCD
> >
> > so after that remap_pfn_range makes Xen complain.
> >
> > (pgprot_noncached(vma->vm_page_prot) == 0x80000000000000b7)
> >
> > If I change prot to
> >
> > vma->vm_page_prot = PAGE_SHARED;
> >
> > (PAGE_SHARED == 0x8000000000000027) then I am able to mmap.
> >
> > Can anyone please help me understand if this is a valid use-case for DomU
> > (pgprot_noncached) and if so why Xen cannot make it?
> >
> > Thank you,
> > Oleksandr
> Superpages are not supported in a PV guest.
>
> You can enable the use of 2mb superpages for PV guests by booting Xen
> with the "allowsuperpage" command line option, but quite a few features
> are broken in combination with PV superpages, and this area has been a
> ripe source of security bugs.
>
> Unprivileged guests (i.e. ones without hardware) are not permitted to
> make mappings with anything other than a writeback memory type, because
> all kinds of chaos can ensue if the guest constructs aliasing mappings
> with different cacheabilities, and it is prohibitively expensive for Xen
> to track for auditing purposes.
>
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel