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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On mar, 2013-11-19 at 15:54 +0000, Jan Beulich wrote:
> >>> On 19.11.13 at 16:42, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:
> > 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.
> 
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 
   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

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

Attachment: signature.asc
Description: This is a digitally signed message part

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