Re: [Xen-devel] [PATCH v3 1/3] libxl/cpumap: Add xc_cpumap_[setcpu, clearcpu, testcpu] to complement xc_cpumap_alloc.

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel