On mer, 2014-06-18 at 16:44 +0100, Ian Campbell wrote:
> On Wed, 2014-06-18 at 16:28 +0200, Dario Faggioli wrote:

> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index c2b143b..663abe2 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -338,6 +338,21 @@
> >  #endif
> >  
> >  /*
> > + * LIBXL_HAVE_BUILDINFO_VCPU_HARD_AFFINITY_ARRAY
> > + *
> > + * If this is defined, then libxl_domain_build_info structure will
> > + * contain vcpu_hard_affinity, an array of libxl_bitmap that contains
> > + * the necessary information to set the hard affinity of each VCPU to
> > + * a set of PCPUs. Libxl will try to pin VCPUs to PCPUs according to
> > + * this list.
> 
> Something needs to describe somewhere how this relates to the existing
> cpumap field. I think they are sort of unioned (i.e. cpumap is applied
> then this new thing can override it)?
> 
Ok, I'll add a note about this here too.

> Is that the most desirable semantics, it seems potentially confusing to
> me. Perhaps cpumap should be ignored if this array is of non-zero size?
> 
As I said in the other reply, yes, I'll see if I can do that.

> > + * The number of libxl_bitmap in the array equals to the maximum number
> > + * of VCPUs. The size of each bitmap is computed basing on the maximum
> > + * number of PCPUs.
> 
> These are all things which the caller is expect to arrange by making
> appropriately sized allocations, not inherent properties of the API, I
> think.
> 
> So "the number of libxl_bitmap in the array *should* be equal". "The
> size of each bitmap should ..." etc.
> 
Will fix. I will also add a check that this is actually what we get from
the caller in libxl_dom.c (where the arrays are consumed).

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)