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

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1224 bytes --]

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?

Regards,
Dario

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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