[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 1/7] xen: vNUMA support for PV guests



>>> On 19.11.13 at 16:42, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:
> On mar, 2013-11-19 at 14:48 +0000, Jan Beulich wrote:
>> Just consider a guest with a Linux configured for just 4
>> CPUs and 2 nodes, but having a config file specifying 16 vCPU-s on
>> 4 virtual nodes?
>> 
> That's a fair point. I can't remember the rationale behind the choice of
> using num_possible_cpus()... ISTR some very early version (probably not
> even shared on xen-devel) of the series using something like NR_CPUS,
> but that would suffer from the same issue, I think.
> 
> Probably, we just overlooked the situation you're describing and though
> that, given we don't allow nr_vcpus > nr_vnodes, using
> num_possible_cpus() ought to be enough. But I see it now.
> 
> So, what would the best option be? Another hypercall (or a special way
> of calling this one) "just" to retrieve the number of vnodes?

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

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.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.