From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 1/7] xen: vNUMA support for PV guests Date: Tue, 19 Nov 2013 17:36:00 +0100 Message-ID: <1384878960.15360.27.camel@Solace> References: <1384806262-12532-1-git-send-email-ufimtseva@gmail.com> <1384806262-12532-2-git-send-email-ufimtseva@gmail.com> <528B7D350200007800104840@nat28.tlf.novell.com> <1384871712.19880.90.camel@Abyss> <528B885702000078001048CF@nat28.tlf.novell.com> <1384875772.15360.6.camel@Solace> <528B97C502000078001049AE@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7894724452306069683==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VioHX-0007XF-Ht for xen-devel@lists.xenproject.org; Tue, 19 Nov 2013 16:36:07 +0000 In-Reply-To: <528B97C502000078001049AE@nat28.tlf.novell.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: Jan Beulich Cc: keir@xen.org, Ian.Campbell@citrix.com, lccycc123@gmail.com, george.dunlap@eu.citrix.com, msw@linux.com, stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com, Elena Ufimtseva , xen-devel List-Id: xen-devel@lists.xenproject.org --===============7894724452306069683== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bTtkAXwpDWaK+RNaYia6" --=-bTtkAXwpDWaK+RNaYia6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mar, 2013-11-19 at 15:54 +0000, Jan Beulich wrote: > >>> On 19.11.13 at 16:42, Dario Faggioli wrot= e: > > So, what would the best option be? Another hypercall (or a special way > > of calling this one) "just" to retrieve the number of vnodes? >=20 > Iirc there's a padding field in the interface structure, which could > be leveraged. But then again you need two counts, and hence it > might be better to simply add two respective fields. Then make > it/them IN/OUT, and rather than filling the arrays when they're > too small just send back the necessary values. (And of course > you'll want to also send back the actual values in case the passed > in ones turned out to large, so the guest would know how many > of the array elements actually have valid data). >=20 > But in the end the fundamental question stands - how was a PV > guest in your so far proposed model supposed to know its number > of vNodes? While for HVM guests you can make this available via > ACPI, that's not an option for PV. >=20 Wait... I'm no longer so sure I'm getting what you say. I'd be inclined to say "by the XENMEM_get_vnuma_info hcall implemented here", but then again, maybe I'm missing something. The hypercall does provide a mean for the guest to retrieve _all_ the virtual topology information, such as: - number of virtual nodes - virtual node memory ranges - virtual cpu to virtual node mapping - virtual node to physical node mapping, for use in (future) in-guest=20 vNUMA aware subsystems (e.g., ballooning) So, if your point is (as I thought) that for properly allocating the buffers for this hypercall to work we need an information only provided by this hypercall itself, then I agree, and that's why I asked what alternative way would be best to retrieve that bit of information. If it's something else, then I don't know. :-) 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) --=-bTtkAXwpDWaK+RNaYia6 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 v1.4.15 (GNU/Linux) iEYEABECAAYFAlKLk3AACgkQk4XaBE3IOsSbUgCdH43jm4kJPZV8/81hHFrTL2zB y3wAnRaSlOayYxUNsuTMw2J7uuZtRWF4 =5HiB -----END PGP SIGNATURE----- --=-bTtkAXwpDWaK+RNaYia6-- --===============7894724452306069683== 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 --===============7894724452306069683==--