From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Hongyang Subject: Re: [PATCH Remus v2 04/10] tools/libxc: introduce DECLARE_HYPERCALL_BUFFER_USER_POINTER Date: Tue, 12 May 2015 17:48:19 +0800 Message-ID: <5551CC63.6050205@cn.fujitsu.com> References: <1431077610-3366-1-git-send-email-yanghy@cn.fujitsu.com> <1431077610-3366-5-git-send-email-yanghy@cn.fujitsu.com> <1431345182.8263.38.camel@citrix.com> <5551A949.5030009@cn.fujitsu.com> <1431418786.16382.42.camel@citrix.com> <5551C6B8.2050308@cn.fujitsu.com> <1431423795.8263.111.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: <1431423795.8263.111.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 Cc: wei.liu2@citrix.com, wency@cn.fujitsu.com, andrew.cooper3@citrix.com, yunhong.jiang@intel.com, eddie.dong@intel.com, xen-devel@lists.xen.org, rshriram@cs.ubc.ca, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 05/12/2015 05:43 PM, Ian Campbell wrote: > On Tue, 2015-05-12 at 17:24 +0800, Yang Hongyang wrote: >> >> On 05/12/2015 04:19 PM, Ian Campbell wrote: >>> On Tue, 2015-05-12 at 15:18 +0800, Yang Hongyang wrote: >>>> >>>> On 05/11/2015 07:53 PM, Ian Campbell wrote: >>>>> On Fri, 2015-05-08 at 17:33 +0800, Yang Hongyang wrote: >>>>>> Define a user pointer that can access the hypercall buffer data >>>>>> Useful when you only need to access the hypercall buffer data >>>>> >>>>> Can you expand on this please, I think the context is a hypercall buffer >>>>> passed as an argument or as a member of a struct. Please describe why >>>>> DECLARE_HYPERCALL_BUFFER_ARGUMENT and/or DECLARE_HYPERCALL_BUFFER_SHADOW >>>>> are not usable here. >>>> >>>> There are cases that we only need to use the hypercall buffer data, and do >>>> not use the xc_hypercall_buffer_t struct. >>>> >>>> DECLARE_HYPERCALL_BUFFER_ARGUMENT will only define a xc_hypercall_buffer_t, >>>> while DECLARE_HYPERCALL_BUFFER_SHADOW do define a user pointer that can allow >>>> us to access the hypercall buffer data but it also define a >>>> xc_hypercall_buffer_t that we don't use, the compiler will report arg unused >>>> error. >>>> >>>> The cases for example: >>>> In send_all_pages(), we only need to use the haypercall buffer data which is a >>>> dirty bitmap, we set the dirty bitmap to all dirty and call send_dirty_pages, >>>> we will not use the xc_hypercall_buffer_t and hypercall to retrive the dirty >>>> bitmap. >>>> In send_some_pages(), we will also only need to use the dirty_bitmap. the >>>> retrive dirty bitmap hypercall are done by the caller. >>> >>> Thanks. Please include the bulk of this description in the commit >>> message. >>> >>> However, perhaps we should just mark the xc_hypercall_buffer_t as >>> potentially unused, by tagging it with __attribute__((unused)), in some >>> or all of the DECLARE_HYPERCALL_* variants. Then I think you could use >>> DECLARE_HYPERCALL_BUFFER_SHADOW as is? >> >> If __attribute__((unused)) won't cause other problems here, I also prefer >> to add this to DECLARE_HYPERCALL_BUFFER_SHADOW instead of create another >> macro, I think only DECLARE_HYPERCALL_BUFFER_SHADOW may need to set this >> attribute because this is a shadow, we might not use the xc_hypercall_buffer_t >> which already allocated. > > We can certainly start from there and consider other such additions as > the need arises. OK, thanks, will do in the next version. > > Ian. > > . > -- Thanks, Yang.