Re: IOCTL_PRIVCMD_MMAPBATCH on Xen 4.13.0

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

>> 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.

The value looks right, and the logs look normal.

~Andrew