Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 04/16/2015 10:00 AM, Ian Campbell wrote:
> On Wed, 2015-04-15 at 17:52 +0100, Wei Liu wrote:
>> On Wed, Apr 15, 2015 at 05:45:15PM +0100, Ian Campbell wrote:
>>> On Wed, 2015-04-15 at 17:36 +0100, Wei Liu wrote:
>>>> On Wed, Apr 15, 2015 at 03:34:48PM +0100, Ian Campbell wrote:
>>>>> On Tue, 2015-04-14 at 18:54 +0100, Wei Liu wrote:
>>>>>> Let's see if we can record this in xc image format. I haven't looked,
>>>>>> but George mentioned that it might be possible to do so.
>>>>>
>>>>> Can this not be done at the save stage in the bit where we update the
>>>>> JSON to reflect the actual configuration?
>>>>>
>>>>
>>>> Yes, it's possible to do that. The value is not in libxl idl simply
>>>> because it's always not there.
>>>
>>> We can't set the existing maxmem then?
>>>
>>
>> If the "we" in your question means an applications that use libxl's
>> public interface, then no. It's not in IDL. It's not in xenstore. That
>> value is currently managed by libxl + libxc + xen.
> 
> I was thinking of libxl_domain_build_info.max_memkb, which is in a
> struct which is marshalled over the wire and which could be updated on
> save to reflect the actual usage.
> 
> Does using that field not work for some reason?

The problem, I think, is that max_memkb says how much memory is
*reported to the guest*.  So what happens when the VM on the other side
reboots?  Won't libxl use this newly-increased max_memkb as the memory
to be reported *to the guest*?  And then qemu will have to allocate *yet
more* memory for its roms?

Meaning that the size of the VM will increase by a few kB (MB?) every
time it reboots?

This is why I think we should try to start making a clear distinction
between "what the guest sees as RAM" and "what xen sees as memory"; And
I proposed using "memory" for what the guest sees, and "pages" for what
Xen sees.

 -George

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