[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IOCTL_PRIVCMD_MMAPBATCH on Xen 4.13.0


  • To: Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Sat, 16 May 2020 17:18:45 +0100
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Sat, 16 May 2020 16:19:27 +0000
  • Ironport-sdr: j41tsxKUU1prgfgu90Dch55mEWG+4gXxGu3+eN8ZjGrlYLLlNJVhY+L9f3YuXp1OK61ylP2Nno hOeXbSNBPyysUoArbyZZGGKIXQIZMe0m0fClvFlmUczWiaLi/aI6Th6Y4JVSM14aaRwselZMJo sEp5HSJPhqblEj4BmLAdKyWqaq0phzrhfBvcctV7cp4O2T7khJ8hWawnKDF+oJsNfNCpG4gQ5a FYrCB2s1iM1ZuFo66GfKrj571l+ZTDu6tVN3MwuU25+MOtpvw7dZw8AF2JeAU93RRg2VXUx6xM Rhs=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.