From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH Remus v1 1/8] tools/libxc: adjust the memory allocation for migration Date: Thu, 7 May 2015 14:57:40 +0100 Message-ID: <1431007060.2660.390.camel@citrix.com> References: <1430980646-316-1-git-send-email-yanghy@cn.fujitsu.com> <1430980646-316-2-git-send-email-yanghy@cn.fujitsu.com> <554B34F7.5000009@citrix.com> <554B6BB6.6050202@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <554B6BB6.6050202@cn.fujitsu.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: Hongyang Yang , David Vrabel Cc: wei.liu2@citrix.com, eddie.dong@intel.com, wency@cn.fujitsu.com, Andrew Cooper , yunhong.jiang@intel.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, rshriram@cs.ubc.ca List-Id: xen-devel@lists.xenproject.org On Thu, 2015-05-07 at 21:42 +0800, Hongyang Yang wrote: > > On 05/07/2015 05:48 PM, Andrew Cooper wrote: > > On 07/05/15 07:37, Yang Hongyang wrote: > >> Move the memory allocation before the concrete live/nolive save > >> in order to avoid the free/alloc memory loop when using Remus. > >> > >> Signed-off-by: Yang Hongyang > >> --- > >> tools/libxc/xc_sr_save.c | 53 +++++++++++++++++++----------------------------- > >> 1 file changed, 21 insertions(+), 32 deletions(-) > >> > >> diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c > >> index 5d9c267..7fed668 100644 > >> --- a/tools/libxc/xc_sr_save.c > >> +++ b/tools/libxc/xc_sr_save.c > >> @@ -3,6 +3,8 @@ > >> > >> #include "xc_sr_common.h" > >> > >> +DECLARE_HYPERCALL_BUFFER(unsigned long, to_send); > > > > This unfortunately causes an issue when concurrent calls to > > xc_domain_save() in the same process. While this is a highly > > ill-advised action, I did try to avoid breaking it. > > > > Please move this declaration into the ctx.save union. > > I know the best way is to put this into ctx.save union, but I haven't > found a method to put it in, the DECLARE_HYPERCALL_BUFFER macro can not > be used there, should I just define a unsigned long var at ctx.save > union, and use other macro(what macro?) define at save()? I think you need a variable of type xc_hypercall_buffer_t in the struct and then to use DECLARE_HYPERCALL_BUFFER_SHADOW in functions which need to access it. DECLARE_HYPERCALL_BUFFER_SHADOW seems to currently be unused, David added it in 60572c972b8d, I suspect to be used by migration v2, although perhaps it never was (at least not in tree yet). Ian.