Re: [Xen-devel] [PATCH for-4.5] xen: vnuma: expose vnode_to_pnode to guest

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote:
> On Mon, 2014-11-10 at 10:00 +0000, Wei Liu wrote:
> > On Mon, Nov 10, 2014 at 09:21:24AM +0000, Jan Beulich wrote:
> > > >>> On 08.11.14 at 20:43, <wei.liu2@xxxxxxxxxx> wrote:
> > > > This information is passed in in domctl hypercall but the guest
> > > > interface doesn't expose it to guest. PV NUMA-aware ballooning relies on
> > > > this piece of information to function properly.
> > > 
> > > Considering that exposing this mapping is wrong from a conceptual
> > > pov (as was discussed during the review of Elena's original series),
> > > the desire to nevertheless expose it would need to be explained
> > > much better than what you did above.
> > > 
> > 
> > My thought was that if a PV guest needs to do NUMA-aware ballooning, it
> > would be easier to have the mapping at hand to let the guest request
> > explicitly from what physical node it wants the page. It was based
> > on my vague memory of early version of Elena's series.
> > 
> Some discussion on this happened while talking about some early work on
> NUMA-aware ballooning. This is a message from that thread:
> 
> http://lists.xenproject.org/archives/html/xen-devel/2013-08/msg01986.html
> 

Phew! That's a year ago. No wonder I don't remember anything...

> > However, if this is conceptually wrong and has been discussed before,
> > (as I said in the other email) please just ignore this patch. I can try
> > to modify the hypervisor instead to make NUMA-aware ballooning happen
> > under the hood without guest knowing anything. That is, to make use of
> > the vmemrange structure to identify the vnode of a particular gpfn, then
> > with vnode_to_pnode map to identify the physical node of that gpfn, then
> > do NUMA-aware ballooning.
> > 
> I'm all for *not* exposing such information to the guest. However, a
> quote from George, from that thread, with which I *totally* agree with,
> is this one:
> 
> <<I would like to point out that to make this [NUMA aware ballooning]
>   work for ballooning *up*, however, there will need to be a way for the
>   guest to specify, "please allocate from vnode X", and have Xen
>   translate the vnode into the appropriate pnode(s).>>
> 
> If this can be done without exposing the mapping, as Wei suggests, then
> I agree we should go for it. If not, we'll have to introduce something
> like this (along with proper documentation of how it should be used) at
> some point.
> 
> 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?
> 

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.

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.

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.

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.

Wei.

> 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)
> 



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