Re: IOCTL_PRIVCMD_MMAPBATCH on Xen 4.13.0

[Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>]

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.

> 
> ioreq_pfn ought to be something just below the 4G boundary, and the
> toolstack ought to put memory there in the first place.  Can you
> identify what value ioreq_pfn has,

You mean, something like:
(gdb) print/x ioreq_pfn
$2 = 0xfeff0

> and whether it matches up with the
> magic gfn range as reported by `xl create -vvv` for the guest?

I guess you mean
xl -vvv create
the output is attached

The kernel says it tries to map 0xfeff0000 to virtual address 0x79656f951000.


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

Attachment: typescript
Description: Text document