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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Apr 15, 2015 at 11:03 AM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> 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.

I would argue that we should start trying to make "memory" mean "pages
that the guest sees as RAM".  Saying "Give this guest 8G of memory"
and then having that eaten away by all the extraneous memory
requirements (VGA ram, &c) seems like a less good option.  If some of
that memory is not exposed to the guest at the moment because, for
instance, the e820 is not being updated, then that's a bug we should
fix separately.

Alternately, we should go the other way and make "memory" mean "Total
pages of RAM the guest can ever have", and take *all* the extra
requirements (VGA, option roms, &c) out of that.

 -George

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