Re: [PATCH RESEND v2 2/2] xen: enable vnuma for PV guest

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Nov 19, 2013 at 03:55:06PM +0000, David Vrabel wrote:
> On 19/11/13 15:19, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 19, 2013 at 02:56:41PM +0000, David Vrabel wrote:
> >> The relevant bits in dummy_numa_init are in the error path of
> >> xen_numa_init().
> > 
> > That seems the wrong place to do it. The top layer calls 
> > in each of the numa implementations and then falls back to
> > the dummy.
> 
> Think of it as not the dummy, but Xen setting the NUMA configuration up
> with only a single node.

Or with multiple nodes if numa=fake is used.

> 
> The useful bits in dummy_numa_init() are two calls to standard functions
> for use by *_numa_init() calls so it just seems easier all round to just
> call then directly than add a dependancy on dummy_numa_init().

My worry is more of the numa_init not being completly executed.

> 
> > Calling from within the implementation on something that is eventually
> > done on the upper level already is not right.
> 
> >From the point of view of the caller, it does the right thing.  NUMA is
> setup.
> 
> >> I do think this approach (using the provided API to setup the single
> >> (dummy) node), is preferable to calling dummy_numa_init().
> > 
> > Doesn't it do the same thing? And also what about if you the user
> > provides fakenuma?
> 
> I don't know what "fakenuma" is refering to.

numa=fake or see arch/x86/mm/numa_emulation.c

Which gets executed if you end up calling: numa_init(X) and 'X'
returns a zero or positive value.

Which it won't as the first thing it the Xen PV NUMA code does
is to see if the hypercall is supported. If not, it bails out - so we
never get to do the 'numa=fake' if a user wanted to.