Re: [Xen-devel] [PATCH v6 03/18] xl / libxl: push VCPU affinity pinning down to libxl

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Jun 10, 2014 at 03:01:00PM +0100, Ian Campbell wrote:
> On Mon, 2014-06-09 at 13:43 +0100, Wei Liu wrote:
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 0ea0464..4765fb6 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -305,6 +305,7 @@ libxl_domain_build_info =
> > Struct("domain_build_info",[
> >      ("avail_vcpus",     libxl_bitmap),
> >      ("cpumap",          libxl_bitmap),
> >      ("nodemap",         libxl_bitmap),
> > +    ("vcpu_affinity",   Array(libxl_bitmap, "num_vcpumaps")),
> 
> Looking at one of Dario's patches I became confused about how this new
> field relates to the existing cpumap field.
> 
> Am I right that the new field is just a per-vcpu version of the old
> (which only allows you to set the affinity of every vcpu together)?
> 

Yes, you're right. The old field denotes the PCPUs this domain is
allowed to run on. The new array specifies the PCPUs each VCPU can run
on.

> Can this relationship be mentioned in the commit message and/or comments
> please.
> 

Sure.

> I also wonder if the name could be changed to better reflect this
> relationship, but I can't actually think of a good name. cpumap_FOO
> where FOO has connotations of per-vcpu/listiness.
> 
> I also just noticed that this change violates the following from
> idl.txt:
>   idl.Array.len_var contains an idl.Field which is added to the parent
>   idl.Aggregate and will contain the length of the array. The field
>   MUST be named num_ARRAYNAME.
> 

I will change lenvar to num_ARRAYNAME.

Wei.

> Ian.
> 
> >      ("numa_placement",  libxl_defbool),
> >      ("tsc_mode",        libxl_tsc_mode),
> >      ("max_memkb",       MemKB),
> 

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