From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v9 5/9] libxl/xl: push VCPU affinity pinning down to libxl Date: Wed, 18 Jun 2014 18:32:40 +0200 Message-ID: <1403109160.21681.22.camel@Solace> References: <20140618141449.21586.55528.stgit@Solace> <20140618142818.21586.48020.stgit@Solace> <1403106254.6568.94.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4594156488279445280==" Return-path: In-Reply-To: <1403106254.6568.94.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Ian.Jackson@citrix.com, Andrew.Cooper3@citrix.com, Wei Liu , George.Dunlap@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============4594156488279445280== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yG4nbe6fp5GIK4isumjx" --=-yG4nbe6fp5GIK4isumjx Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 > > =20 > > /* > > + * 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. >=20 > 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)? >=20 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? >=20 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 numbe= r > > + * of VCPUs. The size of each bitmap is computed basing on the maximum > > + * number of PCPUs. >=20 > These are all things which the caller is expect to arrange by making > appropriately sized allocations, not inherent properties of the API, I > think. >=20 > So "the number of libxl_bitmap in the array *should* be equal". "The > size of each bitmap should ..." etc. >=20 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-yG4nbe6fp5GIK4isumjx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlOhvygACgkQk4XaBE3IOsQoigCeIKI4lZc4yU5zx0y8ZWV6aXof 7uUAoIqDpmtbQeIsx1gu/E7uDfhnIkSu =UVCG -----END PGP SIGNATURE----- --=-yG4nbe6fp5GIK4isumjx-- --===============4594156488279445280== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4594156488279445280==--