From: Jeremy Linton <jeremy.linton@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
linux-acpi@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
vkilari@codeaurora.org,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
austinwc@codeaurora.org, tnowicki@caviumnetworks.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
dietmar.eggemann@arm.com, Will Deacon <will.deacon@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
morten.rasmussen@arm.com, Al Stone <ahs3@redhat.com>,
palmer@sifive.com, Hanjun Guo <hanjun.guo@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-riscv@lists.infradead.org,
John Garry <john.garry@huawei.com>,
wangxiongfeng2@huawei.com,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Len Brown <lenb@kernel.org>
Subject: Re: [PATCH v7 00/13] Support PPTT for ARM64
Date: Thu, 8 Mar 2018 11:41:46 -0600 [thread overview]
Message-ID: <7c69ef2a-5b34-a6ab-d309-3aeb90692019@arm.com> (raw)
In-Reply-To: <CAKv+Gu__yYX-fFqxyxNk3M=Byvw5798po0Jr=qr3anEWKJ+SMA@mail.gmail.com>
Hi,
First thanks for testing this!!
On 03/08/2018 09:59 AM, Ard Biesheuvel wrote:
> On 27 February 2018 at 18:49, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> On 03/01/2018 06:06 AM, Sudeep Holla wrote:
>>>
>>> Hi Jeremy,
>>>
>>> On 28/02/18 22:06, Jeremy Linton wrote:
>>>>
>>>> ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is
>>>> used to describe the processor and cache topology. Ideally it is
>>>> used to extend/override information provided by the hardware, but
>>>> right now ARM64 is entirely dependent on firmware provided tables.
>>>>
>>>> This patch parses the table for the cache topology and CPU topology.
>>>> When we enable ACPI/PPTT for arm64 we map the physical_id to the
>>>> PPTT node flagged as the physical package by the firmware.
>>>> This results in topologies that match what the remainder of the
>>>> system expects. To avoid inverted scheduler domains we then
>>>> set the MC domain equal to the largest cache within the socket
>>>> below the NUMA domain.
>>>>
>>> I remember reviewing and acknowledging most of the cacheinfo stuff with
>>> couple of minor suggestions for v6. I don't see any Acked-by tags in
>>> this series and don't know if I need to review/ack any more cacheinfo
>>> related patches.
>>
>>
>> Hi,
>>
>> Yes, I didn't put them in because I changed the functionality in 2/13 and
>> there is a bug fix in 5/13. I thought you might want to do a quick diff of
>> the git v6->v7 tree.
>>
>> Although given that most of the changes were in response to your comments in
>> v6 I probably should have just put the tags in.
>>
>
> I get sane output from lstopo when applying these patches and booting
> my Socionext SynQuacer in ACPI mode:
>
> $ lstopo-no-graphics
> Machine (31GB)
> Package L#0 + L3 L#0 (4096KB)
> L2 L#0 (256KB)
> L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
> L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)
> L2 L#1 (256KB)
> L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#2)
> L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#3)
> L2 L#2 (256KB)
> L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4 + PU L#4 (P#4)
> L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5 + PU L#5 (P#5)
> L2 L#3 (256KB)
> L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6 + PU L#6 (P#6)
> L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7 + PU L#7 (P#7)
> L2 L#4 (256KB)
> L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8 + PU L#8 (P#8)
> L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9 + PU L#9 (P#9)
> L2 L#5 (256KB)
> L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10 + PU L#10 (P#10)
> L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11 + PU L#11 (P#11)
> L2 L#6 (256KB)
> L1d L#12 (32KB) + L1i L#12 (32KB) + Core L#12 + PU L#12 (P#12)
> L1d L#13 (32KB) + L1i L#13 (32KB) + Core L#13 + PU L#13 (P#13)
> L2 L#7 (256KB)
> L1d L#14 (32KB) + L1i L#14 (32KB) + Core L#14 + PU L#14 (P#14)
> L1d L#15 (32KB) + L1i L#15 (32KB) + Core L#15 + PU L#15 (P#15)
> L2 L#8 (256KB)
> L1d L#16 (32KB) + L1i L#16 (32KB) + Core L#16 + PU L#16 (P#16)
> L1d L#17 (32KB) + L1i L#17 (32KB) + Core L#17 + PU L#17 (P#17)
> L2 L#9 (256KB)
> L1d L#18 (32KB) + L1i L#18 (32KB) + Core L#18 + PU L#18 (P#18)
> L1d L#19 (32KB) + L1i L#19 (32KB) + Core L#19 + PU L#19 (P#19)
> L2 L#10 (256KB)
> L1d L#20 (32KB) + L1i L#20 (32KB) + Core L#20 + PU L#20 (P#20)
> L1d L#21 (32KB) + L1i L#21 (32KB) + Core L#21 + PU L#21 (P#21)
> L2 L#11 (256KB)
> L1d L#22 (32KB) + L1i L#22 (32KB) + Core L#22 + PU L#22 (P#22)
> L1d L#23 (32KB) + L1i L#23 (32KB) + Core L#23 + PU L#23 (P#23)
> HostBridge L#0
> PCIBridge
> PCIBridge
> PCI 1b21:0612
> Block(Disk) L#0 "sda"
> HostBridge L#3
> PCI 10de:128b
> GPU L#1 "renderD128"
> GPU L#2 "card0"
> GPU L#3 "controlD64"
>
> So
>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> *However*, while hacking on the firmware that exposes the table, I
> noticed that a malformed structure (incorrect size) can get the parser
> in an infinite loop, hanging the boot after
>
> [ 8.244281] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [ 8.251780] Serial: AMBA driver
> [ 8.255042] msm_serial: driver initialized
> [ 8.259752] ACPI PPTT: Cache Setup ACPI cpu 0
> [ 8.264121] ACPI PPTT: Looking for data cache
> [ 8.268484] ACPI PPTT: Looking for CPU 0's level 1 cache type 0
>
> so I guess the parsing code could be made a bit more robust?
>
I've been wondering how long it would take for someone to complain about
one of these cases, I added a check in find_processor_node back a few
revisions ago to deal with zero length's causing infinite loops, but the
leaf node check doesn't have one, and that is likely what your hitting.
next prev parent reply other threads:[~2018-03-08 17:41 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-28 22:06 [PATCH v7 00/13] Support PPTT for ARM64 Jeremy Linton
2018-02-28 22:06 ` [PATCH v7 01/13] drivers: base: cacheinfo: move cache_setup_of_node() Jeremy Linton
2018-03-06 16:16 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 02/13] drivers: base: cacheinfo: setup DT cache properties early Jeremy Linton
2018-02-28 22:34 ` Palmer Dabbelt
2018-03-06 16:43 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 03/13] cacheinfo: rename of_node to fw_token Jeremy Linton
2018-03-06 16:45 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 04/13] arm64/acpi: Create arch specific cpu to acpi id helper Jeremy Linton
2018-03-06 17:13 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 05/13] ACPI/PPTT: Add Processor Properties Topology Table parsing Jeremy Linton
2018-03-06 17:39 ` Sudeep Holla
2018-03-08 16:39 ` Ard Biesheuvel
2018-03-08 19:52 ` Jeremy Linton
2018-03-19 10:46 ` Rafael J. Wysocki
2018-03-20 13:25 ` Jeremy Linton
2018-02-28 22:06 ` [PATCH v7 06/13] ACPI: Enable PPTT support on ARM64 Jeremy Linton
2018-03-06 16:55 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 07/13] drivers: base cacheinfo: Add support for ACPI based firmware tables Jeremy Linton
2018-03-06 17:50 ` Sudeep Holla
2018-03-08 17:20 ` Lorenzo Pieralisi
2018-02-28 22:06 ` [PATCH v7 08/13] arm64: " Jeremy Linton
2018-03-03 21:58 ` kbuild test robot
2018-03-06 17:23 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 09/13] ACPI/PPTT: Add topology parsing code Jeremy Linton
2018-02-28 22:06 ` [PATCH v7 10/13] arm64: topology: rename cluster_id Jeremy Linton
2018-03-05 12:24 ` Mark Brown
2018-02-28 22:06 ` [PATCH v7 11/13] arm64: topology: enable ACPI/PPTT based CPU topology Jeremy Linton
2018-02-28 22:06 ` [PATCH v7 12/13] ACPI: Add PPTT to injectable table list Jeremy Linton
2018-02-28 22:06 ` [PATCH v7 13/13] arm64: topology: divorce MC scheduling domain from core_siblings Jeremy Linton
2018-03-01 15:52 ` Morten Rasmussen
2018-02-27 20:18 ` Jeremy Linton
2018-03-06 16:07 ` Morten Rasmussen
2018-03-06 22:22 ` Jeremy Linton
2018-03-07 13:06 ` Morten Rasmussen
2018-03-07 16:19 ` Jeremy Linton
2018-03-14 13:05 ` Morten Rasmussen
2018-03-08 20:41 ` Brice Goglin
2018-03-14 12:43 ` Morten Rasmussen
2018-03-01 12:06 ` [PATCH v7 00/13] Support PPTT for ARM64 Sudeep Holla
2018-02-27 18:49 ` Jeremy Linton
2018-03-08 15:59 ` Ard Biesheuvel
2018-03-08 17:41 ` Jeremy Linton [this message]
2018-03-14 9:57 ` vkilari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c69ef2a-5b34-a6ab-d309-3aeb90692019@arm.com \
--to=jeremy.linton@arm.com \
--cc=ahs3@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=austinwc@codeaurora.org \
--cc=catalin.marinas@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=hanjun.guo@linaro.org \
--cc=john.garry@huawei.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=morten.rasmussen@arm.com \
--cc=palmer@sifive.com \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--cc=tnowicki@caviumnetworks.com \
--cc=vkilari@codeaurora.org \
--cc=wangxiongfeng2@huawei.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox