Re: [Xen-devel] [PATCH v4 8/8] libxl, hvmloader: Don't relocate memory for MMIO hole

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 26 Jun 2013, Hao, Xudong wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxx
> > [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of George Dunlap
> > Sent: Friday, June 21, 2013 6:47 PM
> > To: xen-devel@xxxxxxxxxxxxx
> > Cc: Keir Fraser; Ian Campbell; Hanweidong; George Dunlap; Stefano 
> > Stabellini;
> > Ian Jackson
> > Subject: [Xen-devel] [PATCH v4 8/8] libxl, hvmloader: Don't relocate memory 
> > for
> > MMIO hole
> > 
> > At the moment, qemu-xen can't handle memory being relocated by
> > hvmloader.  This may happen if a device with a large enough memory
> > region is passed through to the guest.  At the moment, if this
> > happens, then at some point in the future qemu will crash and the
> > domain will hang.  (qemu-traditional is fine.)
> > 
> > It's too late in the release to do a proper fix, so we try to do
> > damage control.
> > 
> > hvmloader already has mechanisms to relocate memory to 64-bit space if
> > it can't make a big enough MMIO hole.  By default this is 2GiB; if we
> > just refuse to make the hole bigger if it will overlap with guest
> > memory, then the relocation will happen by default.
> > 
> 
> For qemu-xen use case, hvmloader start MMIO hole at 0xf0000000. However, 
> qemu-xen initialize ram region to 0xf0000000(HVM_BELOW_4G_RAM_END) below 4G, 
> and pci hole starting from 0xe0000000, is it overlap?

hvmloader configures the MMIO hole to start at 0xf0000000, qemu-xen
configures the below_4g_mem_size ram region to *end* at 0xf0000000 and
the pci hole to start from 0xf0000000. It's all coherent now.

The patch to modify the pci hole in qemu-xen and have it start at
0xe0000000 has been reverted.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel