Re: [PATCH RFC 1/2] linux/vnuma: vnuma support for pv guest

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2629 bytes --]

On mer, 2013-08-28 at 09:38 -0700, Matt Wilson wrote:
> On Wed, Aug 28, 2013 at 12:01:48PM -0400, Konrad Rzeszutek Wilk wrote:
> > That would also parallel the work you do with ACPI right?
> 
> Yes.
> 
I see. It's hard to comment, since I have only seen some previous (off
list) versiona of Elena's code (and won't have time to properly review
this one untill Monday), and I haven't seen Matt's code at all... 

Anyway...

> > We could enable ACPI parsing in a PV guest and provide one table - the
> > SLIT (or SRAT).
> 
> Right, it'd be the SRAT table for the resource affinity and a SLIT
> table for the locality/distance information.
> 
... I see the point in sharing code for HVM and PV. However, I'm still
not convinced this would be something valuable to do with this specific
hunk, mostly because it looks really easy and clean to hook up at the
numa_init() stage (i.e., what Elena is doing), that anything else I can
think of looks like more work. :-P

> > But I don't know enough about SRAT to know whether this is something
> > that represents truly everything we need?
> 
> The SRAT table has processor objects and memory objects. A processor
> object maps a logical processor number to its initial APIC ID and
> provides the node information. A memory object specifies the start and
> length for a memory region and provides the node information.
> 
> For SLIT, the entries are a matrix of distances.
> 
> Here are the structs:
> 
> [snip]
>
Ok, thanks for the very useful info. What would be interesting to know
is where and how Linux reads the information from ACPI and fill these
structures.

The current Elena's approach is 1 hypercall, during early NUMA
initialization, and that is pretty self-contained (which is the thing I
like most about it).

How easy is it to look up the places where each one of the tables gets
filled, intercept the code/calls doing that, and replace it properly for
our use case? How easy is it to "xen-ify" those call sites (stuff like
'#ifdef CONFIG_XEN' or/and is_xen_domain() )? How many hypercalls would
it require? Is it possible to have one doing all the work, or would we
need something like one for each table?

As I said, I can't check the details about it right now, but it sounds
like more work than Elena's xen_numa_init().

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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