Re: IOCTL_PRIVCMD_MMAPBATCH on Xen 4.13.0

[Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>]

On Sat, May 16, 2020 at 05:18:45PM +0100, Andrew Cooper wrote:
> On 15/05/2020 22:53, Manuel Bouyer wrote:
> > On Fri, May 15, 2020 at 10:38:13PM +0100, Andrew Cooper wrote:
> >>> [...]
> >>> Does it help ?
> >> Yes and no.  This is collateral damage of earlier bug.
> >>
> >> What failed was xen_init_fv()'s
> >>
> >>     shared_page = xc_map_foreign_range(xc_handle, domid, XC_PAGE_SIZE,
> >>                                        PROT_READ|PROT_WRITE, ioreq_pfn);
> >>     if (shared_page == NULL) {
> >>         fprintf(logfile, "map shared IO page returned error %d\n", errno);
> >>         exit(-1);
> >>     }
> >>
> >> because we've ended up with a non-NULL pointer with no mapping behind
> >> it, hence the SIGSEGV for the first time we try to use the pointer.
> >>
> >> Whatever logic is behind xc_map_foreign_range() should have returned
> >> NULL or a real mapping.
> > What's strange is that the mapping is validated, by mapping it in
> > the dom0 kernel space. But when we try to remap in in the process's
> > space, it fails.
> 
> Hmm - this sounds like a kernel bug I'm afraid.

no I don't think it is. It works with Xen 4.11, and it works with 4.13 for
PV/PVH domUs. Maybe there's a missing flag in the PTE of some sort that is
mandatory for 4.13 but not 4.11 for userland PTE but it doens't look obvious.

The difference could be that the kernel page tables are active when
mapping the foreing page in the dom0's kernel space, but the
user process page table it not (obviously, as we're in the kernel
when doing the mapping).

-- 
Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>
     NetBSD: 26 ans d'experience feront toujours la difference
--