From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugene Fedotov Subject: Fwd: Re: [PATCH RESEND v5 6/6] xen/arm: Implement toolstack for xl restore/save and migrate Date: Wed, 13 Nov 2013 16:25:45 +0400 Message-ID: <52836FC9.8060707@samsung.com> References: <52836DCA.7080206@samsung.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6102455631237402495==" Return-path: In-reply-to: <52836DCA.7080206@samsung.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============6102455631237402495== Content-type: multipart/alternative; boundary=------------000709050300060408020601 This is a multi-part message in MIME format. --------------000709050300060408020601 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. At the proof-of-concept stage there was easier to transfer it inside xc_domain_save and xc_domain_restore rather then patching libxl. 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. Best regards, Evgeny --------------000709050300060408020601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 












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. 
At the proof-of-concept stage there was easier to transfer it inside 
xc_domain_save and xc_domain_restore rather then patching libxl.
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.

Best regards,
Evgeny



--------------000709050300060408020601-- --===============6102455631237402495== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6102455631237402495==--