Re: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT

[Tomasz Nowicki]

On 07.09.2015 16:04, Anaczkowski, Lukasz wrote:
> From: Tomasz Nowicki [mailto:tomasz.nowicki@xxxxxxxxxx]
> Sent: Tuesday, September 1, 2015 3:37 PM
> > On 01.09.2015 14:07, Anaczkowski, Lukasz wrote:
> > > From: Tomasz Nowicki [mailto:tomasz.nowicki@xxxxxxxxxx]
> > > Sent: Tuesday, September 1, 2015 10:03 AM
> > > > > To fix this, each LAPIC/X2APIC entry from MADT table needs to be
> > > > > handled at the same time when processing it, thus adding
> > > > > acpi_subtable_proc structure which stores
> > > > > () ACPI table id
> > > > > () handler that processes table
> > > > > () counter how many items has been processed and passing it to
> > > > > acpi_table_parse_entries().
> > >
> > > > Why can't you leave the parsing code as is and create ApicId sorted list while parsing LAPIC/X2APIC? You could call acpi_register_lapic() after all... Do I miss something ?
> > >
> > > Just to make sure I understand correctly - you suggest to replace
> > > calls to acpi_register_lapic() with a code that builds an APIC ID list while parsing LAPIC/X2APIC, and after parsing is done, go thru the list and call acpi_register_lapic() on each APIC ID, correct?
> >
> > Yes, does it work for you?
>
> Hi Tomasz, sorry for late response, I was distracted by other things.
>
> So, I see two options to build the list:
>
> (a) use APIC ID as the table index
> (b) always append APIC ID to the end of table, in the order that BIOS lists them
>
> Also, my goal is to end up with enumeration like this (assuming there's 72 cores, 4 hyper threads each, total 288 logical CPUs):
>
> APIC ID  ->    Logical ID
> 0              ->     0
> 1              ->     72
> 2              ->     144
> 3              ->     216
> 4              ->     1
> 5              ->     73
> 6              ->     145
> 7              ->     217
> 8              ->     2
> ...
> 284         ->      71
> 285         ->      143
> 286         ->      215
> 287         ->      287
>
> Note that n,n+1,n+2,n+3 APIC IDs share same physical core, while being separated by core count in logical listing (e.g. 0,72,144,216 share same physical core).
>
> Now, ACPI spec specifies how APIC IDs should be listed:
> (1) Boot processor is listed first
> (2) For multi-threaded processors, BIOS should list the first logical processor of each of the individual multi-threaded processors in MADT before listing any of the second logical processors.
> (3) APIC IDs < 0xFF should be listed in APIC subtable, APIC IDs >= 0xFF should be listed in X2APIC subtable
>
> Keeping in mind above, BIOS lists APIC IDs as:
>
> APIC (0,4,8, .., 252)
> X2APIC (256,260,264, .. 284)
> APIC (1,5,9,...,253)
> X2API (257,261,265, 285)
> etc

OK got it, your patches make sense then.

Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/