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

[Elena Ufimtseva <ufimtseva@xxxxxxxxx>]

Hi Matt

Do you construct these tables via hypercalls?
Will be good to see the details on how you do it and if I can use it as well.
Thank you.

Elena

On Wed, Aug 28, 2013 at 12:38 PM, Matt Wilson <msw@xxxxxxxxxx> wrote:
> On Wed, Aug 28, 2013 at 12:01:48PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Tue, Aug 27, 2013 at 06:37:35PM -0700, Matt Wilson wrote:
>> > On Tue, Aug 27, 2013 at 06:27:15PM -0700, Matt Wilson wrote:
>> > > On Tue, Aug 27, 2013 at 04:52:59AM -0400, Elena Ufimtseva wrote:
>> > > > Uses subop hypercall to request XEN about vnuma topology.
>> > > > Sets the memory blocks (aligned by XEN), cpus, distance table
>> > > > on boot. NUMA support should be compiled in kernel.
>> > >
>> > > Are we *really sure* that we want to go this route for PV vNUMA?
>> > > Couldn't we build just enough(tm) of the ACPI tables to express the
>> > > NUMA topology when constructing the domain? That's what we do for the
>> > > e820 map.
>> >
>> > Ignore me somewhat, since the e820 information is retrieved via
>> > hypercall similar to what you're proposing.
>> >
>> > Still, if there's some way that we can reuse existing Linux code
>> > rather than bolting on a completely parallel mechanism to set this up
>> > under PV I think it'd be better.
>>
>> That would also parallel the work you do with ACPI right?
>
> Yes.
>
>> 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.
>
>> 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:
>
> struct acpi_20_srat_processor {
>     uint8_t type;
>     uint8_t length;
>     uint8_t domain;
>     uint8_t apic_id;
>     uint32_t flags;
>     uint8_t sapic_id;
>     uint8_t domain_hi[3];
>     uint32_t reserved;
> };
>
> struct acpi_20_srat_memory {
>     uint8_t type;
>     uint8_t length;
>     uint8_t domain;
>     uint8_t domain_hi[3];      /* this is ACPI 3.0, reserved in 2.0 */
>     uint16_t reserved;
>     uint32_t base_address_lo;
>     uint32_t base_address_hi;
>     uint32_t length_lo;
>     uint32_t length_hi;
>     uint32_t reserved2;
>     uint32_t flags;
>     uint32_t reserved3[2];
> };
>
> struct acpi_20_slit {
>     struct acpi_header header;
>     uint64_t nr_sys_loc;
>     uint8_t  entry[];
> };
>
> --msw



-- 
Elena

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