Re: [Xen-devel] [PATCH v2 1/1] tools: Handle xc_maxmem adjustments

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 15 Apr 2015, Andrew Cooper wrote:
> On 15/04/15 10:57, Stefano Stabellini wrote:
> > On Wed, 15 Apr 2015, Andrew Cooper wrote:
> >> On 14/04/15 23:06, Don Slutz wrote:
> >>> This fixes an issue where "xl save" followed by "xl restore" reports:
> >>> "xc: error: Failed to allocate memory for batch.!: Internal error"
> >>>
> >>> One of the ways to get into this state is to have more then 4 e1000
> >>> nics configured.
> >>>
> >>> Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx>
> >> I still don't think this is the correct solution, although I will
> >> concede that this is a far better patch than v1.
> >>
> >> Going back to the original problem, why does Qemu need to change maxmem
> >> in the first place?  You talk about e1000 option roms, but the option
> >> roms themselves must be allocated in an appropriate PCI bridge window.
> > QEMU allocates actual memory to store the option roms using
> > xc_domain_populate_physmap_exact, increasing the total amount of ram
> > allocated to the guest. QEMU needs to increase maxmem too, otherwise
> > memory allocations will fail after a few option roms.
> 
> It doesn't need to.  The domain already has that much ram allocated to
> itself and otherwise wasted.  Qemu should reuse that ram rather than
> wasting more.

QEMU has no knowledge about what the e820 contains and considers the
memory relocated from the PCI hole to the top of ram as valid guest
memory. Libxl tells QEMU how big the PCI hole is by passing
max-ram-below-4g to QEMU.

I think that we should fix the guest e820 as it is actually valid guest
memory.

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