From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode to guest Date: Mon, 10 Nov 2014 12:42:07 +0100 Message-ID: <1415619727.3717.28.camel@Abyss> References: <1415475807-8699-1-git-send-email-wei.liu2@citrix.com> <546091A40200007800045E86@mail.emea.novell.com> <20141110100016.GA17065@zion.uk.xensource.com> <1415616688.3717.16.camel@Abyss> <20141110110936.GA28360@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3747665096252345347==" Return-path: In-Reply-To: <20141110110936.GA28360@zion.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: Wei Liu Cc: Jan Beulich , Elena Ufimtseva , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============3747665096252345347== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yW/A62xvMkU68UCLArJ2" --=-yW/A62xvMkU68UCLArJ2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2014-11-10 at 11:09 +0000, Wei Liu wrote: > On Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote: > > > I'm 100% ok to re-start that discussion here and now... however, how > > stable should this interface be? Can't we deal with this when actually > > implementing NUMA aware ballooning and add stuff at than point, if > > necessary? > >=20 > The risk would be any new guests with extended get_vnumainfo interface > won't be able to run on old hypervisor (4.5) without proper versioning. >=20 Right. > So basically we have three choices: > 1. Expose vnode_to_pnode in hypercall interface. > 2. Expose the mapping in xenstore. > 3. Don't expose anything, everything happens automagically without guest > knowing anything. >=20 > I'm fine with any of those three. However, Jan suggested in that one > year old thread it would be wrong for the guest to know the mapping, so > I think he implicitly voted for the third option. >=20 Option 3 is the best IMO too. The guest, ideally, should know nothing about how Xen mapped its virtual NUMA nodes onto the host RAM. The question here is how effective that is. As of now, it's quite hard to judge whether we'll be able to do everything automatically, I think. I read your proposal, and it looks sensible, I'm just saying it's hard to be conclusive at this stage. > I only need to make sure that we don't miss option 1 and release > incomplete interface for 4.5. That's why I kick off this discussion. If > we release the interface as it is now and find out we need to expose > mapping later, we would neither 1) do versioning 2) have yet another > interface to return mapping. >=20 Exactly. Personally, I'd keep the mapping out of the interface we already have checked in. If it will reveal impossible to do things completely automatically, I don't think it will be too terrible to add a new specific hypercall. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-yW/A62xvMkU68UCLArJ2 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 iEYEABECAAYFAlRgpI8ACgkQk4XaBE3IOsRjBACcDOM8VMR9baM+DOo0pw46B9S/ dbkAnRJioDi9l9VRpoZTBIrd/xig2kpx =FDaZ -----END PGP SIGNATURE----- --=-yW/A62xvMkU68UCLArJ2-- --===============3747665096252345347== 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 --===============3747665096252345347==--