Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1220191

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

From "Anaczkowski, Lukasz" <lukasz.anaczkowski@intel.com>
Newsgroups linux.kernel
Subject RE: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT
Date 2015-09-07 16:10 +0200
Message-ID <q65ho-7Mu-13@gated-at.bofh.it> (permalink)
References (1 earlier) <q1MZH-4is-7@gated-at.bofh.it> <q1MZH-4is-5@gated-at.bofh.it> <q3ONI-Jq-11@gated-at.bofh.it> <q3SxY-65L-17@gated-at.bofh.it> <q3TX5-7YE-33@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


From: Tomasz Nowicki [mailto:tomasz.nowicki@linaro.org] 
Sent: Tuesday, September 1, 2015 3:37 PM
> On 01.09.2015 14:07, Anaczkowski, Lukasz wrote:
>> From: Tomasz Nowicki [mailto:tomasz.nowicki@linaro.org]
>> 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

so in the end (2) rule is followed.

So, when (a) indexing is selected, mapping will be like:
APIC ID   -> Logical ID
0               ->    0
1               ->    1
2               ->    2
3               ->    3
...
287               ->    287

If (b) indexing is selected, mapping is like:
APIC ID     ->    Logical ID
0                 ->     0
1                 ->     63
2                 ->     126
3                 ->     189
4                 ->     1
5                 ->     64
...
284            ->     256
285            ->     266
286            ->     276
287            ->     286

Why? Because first APIC entries will be in the list (since this is the first parser to run), and just then X2APIC entries will be in the list.

So, long story short, unless you see other simple option on how to build the list of APIC IDs, I'm sorry to say that this approach will not work.

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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

RE: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT "Anaczkowski, Lukasz" <lukasz.anaczkowski@intel.com> - 2015-08-26 09:10 +0200
  Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT Marc Zyngier <marc.zyngier@arm.com> - 2015-08-26 12:50 +0200
    Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2015-08-26 13:50 +0200
      Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT Marc Zyngier <marc.zyngier@arm.com> - 2015-08-26 14:50 +0200
        [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-08-26 19:50 +0200
          Re: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2015-08-27 11:40 +0200
            [PATCH 4/4] x86, acpi: Handle apic/x2apic entries in MADT in correct order Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-08 13:10 +0200
              Re: [PATCH 4/4] x86, acpi: Handle apic/x2apic entries in MADT in  correct order Marc Zyngier <marc.zyngier@arm.com> - 2015-09-08 17:30 +0200
            [PATCH 2/4] x86, arm64, acpi: Added acpi_subtable_proc Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-08 13:10 +0200
              [PATCH 3/4] acpi: multi proc support Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-08 13:10 +0200
            Re: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-08 13:10 +0200
              [PATCH 1/4] acpi: rename acpi_table_parse_entries Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-08 13:10 +0200
              [PATCH 0/4] Fix how CPUs are enumerated when there's more than 255 CPUs Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-08 13:10 +0200
                Re: [PATCH 0/4] Fix how CPUs are enumerated when there's more than  255 CPUs Marc Zyngier <marc.zyngier@arm.com> - 2015-09-08 18:30 +0200
                Re: [PATCH 0/4] Fix how CPUs are enumerated when there's more than  255 CPUs Al Stone <ahs3@redhat.com> - 2015-09-09 00:50 +0200
                RE: [PATCH 0/4] Fix how CPUs are enumerated when there's more than  255 CPUs "Anaczkowski, Lukasz" <lukasz.anaczkowski@intel.com> - 2015-09-09 09:10 +0200
                [PATCH 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-09 11:40 +0200
                [PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-09 11:40 +0200
                Re: [PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in  correct order Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2015-09-09 16:00 +0200
                RE: [PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in  correct order "Anaczkowski, Lukasz" <lukasz.anaczkowski@intel.com> - 2015-09-09 16:40 +0200
                Re: [PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in  correct order Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2015-09-09 17:50 +0200
                Re: [PATCH 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers Marc Zyngier <marc.zyngier@arm.com> - 2015-09-09 12:50 +0200
                [PATCH v4 0/2] Fix how CPUs are enumerated when there's more than 255 CPUs Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-09 15:50 +0200
                [PATCH v4 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-09 15:50 +0200
                [PATCH v4 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-09 15:50 +0200
                Re: [PATCH v4 0/2] Fix how CPUs are enumerated when there's more than 255 CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-09 22:20 +0200
                Re: [PATCH v4 0/2] Fix how CPUs are enumerated when there's more than 255 CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-19 00:20 +0200
                Re: [PATCH 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-09 15:50 +0200
                [PATCH 0/2] Fix how CPUs are enumerated when there's more than 255 CPUs Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-09-09 11:40 +0200
          Re: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT Ingo Molnar <mingo@kernel.org> - 2015-08-28 10:40 +0200
          Re: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT Tomasz Nowicki <tomasz.nowicki@linaro.org> - 2015-09-01 10:10 +0200
            RE: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT "Anaczkowski, Lukasz" <lukasz.anaczkowski@intel.com> - 2015-09-01 14:10 +0200
              Re: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT Tomasz Nowicki <tomasz.nowicki@linaro.org> - 2015-09-01 15:40 +0200
                RE: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT "Anaczkowski, Lukasz" <lukasz.anaczkowski@intel.com> - 2015-09-07 16:10 +0200
                Re: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT Tomasz Nowicki <tn@semihalf.com> - 2015-09-08 16:50 +0200
        Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> - 2015-08-26 19:50 +0200

csiph-web