From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v3 1/3] libxl/cpumap: Add xc_cpumap_[setcpu,
 clearcpu, testcpu] to complement xc_cpumap_alloc.
Date: Wed, 25 Mar 2015 11:01:19 +0000
Message-ID: <1427281279.10784.61.camel@citrix.com>
References: <1427211559-15185-1-git-send-email-konrad.wilk@oracle.com>
	<1427211559-15185-2-git-send-email-konrad.wilk@oracle.com>
	<1427219164.10784.7.camel@citrix.com>
	<1427273263.2560.227.camel@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Yaj3r-0004v9-Kv
	for xen-devel@lists.xenproject.org; Wed, 25 Mar 2015 11:01:23 +0000
In-Reply-To: <1427273263.2560.227.camel@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, George Dunlap <George.Dunlap@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On Wed, 2015-03-25 at 08:47 +0000, Dario Faggioli wrote:
> On Tue, 2015-03-24 at 17:46 +0000, Ian Campbell wrote:
> > On Tue, 2015-03-24 at 11:39 -0400, Konrad Rzeszutek Wilk wrote:
> 
> > > +void xc_cpumap_clearcpu(int cpu, xc_cpumap_t map)
> > > +{
> > > +    clear_bit(cpu, (unsigned long *)map);
> > 
> > Is it necessary to worry about alignment here, since xc_cpumap_t is
> > actually a uint8_t*.
> >
> > [..]
> >
> > Or do we rely on all of these always being dynamically allocated (via
> > xc_cpumap_alloc) and therefore "suitably aligned so that it may be
> > assigned to a pointer to any type of object"[0]  following calloc ,
> > avoids the issue in practice?
> > 
> > I think we probably do, does anyone disagree with that assessment?
> > 
> FWIW, I agree with it.
> 
> The only use case that deviates from that which I could find is:
> 
> xc_vcpu_setaffinity()
>   |
>   --> xc_hypercall_bounce_pre() ==
>       xc__hypercall_bounce_pre()
>         |
>         --> xc__hypercall_buffer_alloc()
>               |
>               --> xc__hypercall_buffer_alloc_pages()
>                     |
>                     --> hypercall_buffer_cache_alloc() ||
>                         linux_privcmd_alloc_hypercall_buffer() (or OS speific variants)
> 
> which is probably still fine, isn't it?

Might we use test_bit and friends on a hypercall buffer directly? I
didn't expect so.

I think it would be safe none the less, since it is all page aligned,
but someone would need to check I didn't do something smarter for small
allocations at some point..

> 
> Regards,
> Dario