Re: IOCTL_PRIVCMD_MMAPBATCH on Xen 4.13.0

[Manuel Bouyer <bouyer@antioche.eu.org>]

On Mon, May 18, 2020 at 08:36:24AM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Manuel Bouyer
> > Sent: 17 May 2020 18:56
> > To: Andrew Cooper <andrew.cooper3@citrix.com>
> > Cc: xen-devel@lists.xenproject.org
> > Subject: Re: IOCTL_PRIVCMD_MMAPBATCH on Xen 4.13.0
> > 
> > On Sun, May 17, 2020 at 07:32:59PM +0200, Manuel Bouyer wrote:
> > > I've been looking a bit deeper in the Xen kernel.
> > > The mapping is failed in ./arch/x86/mm/p2m.c:p2m_get_page_from_gfn(),
> > >         /* Error path: not a suitable GFN at all */
> > > 	if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_pod(*t) ) {
> > > 	    gdprintk(XENLOG_ERR, "p2m_get_page_from_gfn2: %d is_ram %ld is_paging %ld is_pod %ld\n", *t,
> > p2m_is_ram(*t), p2m_is_paging(*t), p2m_is_pod(*t) );
> > > 	    return NULL;
> > > 	}
> > >
> > > *t is 4, which translates to p2m_mmio_dm
> > >
> > > it looks like p2m_get_page_from_gfn() is not ready to handle this case
> > > for dom0.
> > 
> > And so it looks like I need to implement osdep_xenforeignmemory_map_resource()
> > for NetBSD
> > 
> 
> It would be a good idea but you shouldn't have to.

This is how I read the code too, it should fallback to mmapbatch.
But mmapbatch doesn't work in all cases on 4.13.0

> Also, qemu-trad won't use it even if it is there.

Looks like it still use mmapbatch for some mappings, indeeed.
But now it goes a bit further, but still end up failing to map the guest's
memory.

Also, with some fix I got qemu-xen working building on NetBSD, it starts
but fails to load the BIOS rom. Once again p2m_get_page_from_gfn() fails
to find a page, and thinks the type is p2m_mmio_dm.

From what I found it seems that all unallocated memory is tagged p2m_mmio_dm,
is it right ? That would point to some issue allocating RAM for
the domU in qemu, I would need to find where this happens in qemu.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--