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

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 04/14/15 04:53, Wei Liu wrote:
> On Mon, Apr 13, 2015 at 07:51:31PM -0400, Don Slutz wrote:
>> On 04/13/15 12:25, Andrew Cooper wrote:
>>> On 13/04/15 17:09, Don Slutz wrote:
>>>> If QEMU has called on xc_domain_setmaxmem to add more memory for
>>>> option ROMs, domain restore needs to also increase the memory.
>>>>
>>>> Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx>
>>> hvmloader has no interaction with xc_domain_restore().
>> I did not mean to imply that it did.  Somehow I lost the fact that this
>> is a bug in master:
>>
>> [root@dcs-xen-52 don]# xl cre -p /home/don/e1000x8.xfg

>> The page data is correctly saved into the save file (migration stream). 
>> However when
>> the new domain is created, it's size is "wrong".  You cannot adjust any
>> of the config info to fix the size, because the option ROM space to
>> reserve is not an existing config option.   So if I am following you
>> correctly, libxl needs to add and process more info to handle this case.
>>
> Thanks for the analysis. I think what you need to do is to adjust the
> memory size during domain creation in libxl, then the relevant data is
> saved at creation time. It should not be modified during restore.
>
> There is already various adjustments to memory related values in libxl.
> Grep video_memkb and mex_memkb in libxl.

I am assuming you mean max_memkb (since I cannot find mex_memkb).  And it
has the "hack" adjustment of "max_memkb + LIBXL_MAXMEM_CONSTANT".

> Is there a way to know how much more memory each option rom needs? If
> so, you can correctly account for the extra memory you need. This would
> be an ideal fix to this problem.

I do not know of a way to get this info.  It can change based on the
QEMU version.


The static define:

tools/libxl/libxl_internal.h:#define LIBXL_MAXMEM_CONSTANT 1024

Is the the old xl "hack" that allows Xen 4.5 (and before) to support up
to 4 e1000 nics.


   -Don Slutz

> Wei.
>
>>> The migration path should not be hacked up to fix a higher level
>>> toolstack bug.
>> I do not see how QEMU is part of the "higher level toolstack".  If you
>> mean xl vs xc, then
>> I can see "xl save" some how doing the work.  This patch works for me,
>> but I am happy to
>> explore other ways to fix this bug.
>>
>>    -Don Slutz
>>
>>> ~Andrew


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