From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hongyang Yang Subject: Re: [PATCH Remus v1 1/8] tools/libxc: adjust the memory allocation for migration Date: Fri, 8 May 2015 17:11:23 +0800 Message-ID: <554C7DBB.1040806@cn.fujitsu.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> <1431007060.2660.390.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1431007060.2660.390.camel@citrix.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: Ian Campbell , 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 Hi Ian, On 05/07/2015 09:57 PM, Ian Campbell wrote: > 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). Thank you for the information, I finally found the way to use it, but I had to add a new macro DECLARE_HYPERCALL_BUFFER_USER_POINTER which let me to define a user pointer to access the buffer data, because in send_all_pages() I only need to access the buffer data, if I use DECLARE_HYPERCALL_BUFFER_SHADOW, it will define a shadow hypercall buffer which I don't use and the compiler will report unused var error. I will send out v2 series which you can see clearly what I've described above. > > Ian. > > . > -- Thanks, Yang.