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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Apr 14, 2015 at 01:34:43PM -0400, Don Slutz wrote:
> 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".
> 

No, I mean proper accounting.

> > 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.
> 

Hmm... We need to figure out another way.

> 
> 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.
> 

Let's not add more similar hacks again. Removing an old hack doesn't
justify adding a more complex one.

Wei.

> 
>    -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