Re: [Xen-devel] [PATCH RESEND v5 6/6] xen/arm: Implement toolstack for xl restore/save and migrate

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

Readding the list...

On Wed, 2013-11-13 at 12:19 +0000, Ian Campbell wrote:
> On Wed, 2013-11-13 at 16:17 +0400, Eugene Fedotov wrote:
> > 13.11.2013 15:09, Ian Campbell wrote:
> > > For my tests guest config information is not transferred for ARM case
> > > from high-level stack. At the migration receiver side toolstack always
> > > create a new domain with vcpus=1 and default max. mem. So we have to
> > > send guest information as our local guest_params structure (at the
> > > beginning of migration).
> > > It is easy way to work "xl save" or "xl migrate" without modification of
> > > libxl level, but you may have another idea?
> > > Also, toolstack_restore callback is not set (NULL) for ARM case.
> > > So you aren't using xl to do the migration? This is what we should
> > > ultimately be aiming for. It is almost certainly going to require fixes
> > > at the libxl level though.
> > Some misunderstanding. We are using xl for migration.  I mean that libxl 
> > doesn't correctly transfer guest parameters:  number of vcpus, memory. 
> 
> Huh, I'd have thought that would all be taken care of by generic libxl
> code and not require x86 and arm specifics. Maybe I'm wrong.
> 
> In any case it should be fixed.
> 
> > At the proof-of-concept stage there was easier to transfer it inside 
> > xc_domain_save and xc_domain_restore rather then patching libxl.
> 
> Understood.
> 
> > For example, we should correctly set maximum memory for destination 
> > domain by using xc_setmaxmem hypercall. Otherwise, toolstack set it by 
> > default calling
> > xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + 
> > LIBXL_MAXMEM_CONSTANT);
> > (see libxl_dom.c:241). But we don't need to add LIBXL_MAXMEM_CONSTANT on 
> > ARM, so we set it manually.
> 
> This is added on create, so why not on restore? Whether or not it is
> necessary on ARM is a separate question, it should be consistent.
> 
> Ian.



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