Re: [RFC PATCH] arm64: topology: Map PPTT node offset to logic physical package id

[Andrew Jones]

On Thu, Jun 28, 2018 at 10:38:24AM +0100, Sudeep Holla wrote:
> Hi Shunyong,
> 
> On 28/06/18 10:18, Shunyong Yang wrote:
> > As PPTT spec doesn't define the physical package id,
> > find_acpi_cpu_topology_package() will return offset of the node with
> > Physical package field set when querying physical package id. So, it
> > returns 162(0xA2) in following example.
> > 
> > [0A2h 0162   1]                Subtable Type : 00 [Processor Hierarchy
> > Node]
> > [0A3h 0163   1]                       Length : 1C
> > [0A4h 0164   2]                     Reserved : 0000
> > [0A6h 0166   4]        Flags (decoded below) : 00000003
> >                             Physical package : 1
> >                      ACPI Processor ID valid : 1
> > [0AAh 0170   4]                       Parent : 00000000
> > [0AEh 0174   4]            ACPI Processor ID : 00001000
> > [0B2h 0178   4]      Private Resource Number : 00000002
> > [0B6h 0182   4]             Private Resource : 0000006C
> > [0BAh 0186   4]             Private Resource : 00000084
> > 
> > So, when "cat physical_package" in /sys/devices/system/cpu/cpu0/topology/,
> > it will output 162(0xA2). And if some items are added before the node
> > above, the output will change to other value.
> > 
> > This patch maps the node offset to a logic package id. It maps the first
> > node offset to 0, the second to 1, and so on.
> > 
> > Then, it will not output a big value, such as 162 above. And it will
> > not change when some nodes(Physical package not set) are added.
> > 
> > And as long as the nodes with Physical package field set in PPTT keeps
> > the real hardware order, the logic id can map to hardware package id to
> > some extent.
> > 
> > Hope to get feedback from you.
> 
> Thanks for the patch, but Andrew Jones has also posted a patch[1] which
> I had a look but was not sure what is the best approach to fix it yet.
> I will think about it and respond to that.
>

I'll send a v1 yet today. The RFC version was actually OK, as the concern
with ACPI nodes not being in the expected order wasn't actually a problem.
The thread-id or core-id would only be reset to zero when a yet to be
remapped core-id (and all its peers) was found when iterating the PEs.
Since all peers were handled at the same time, the counter reset was
correct, even when the ACPI nodes were out-of-order. The code didn't make
that very obvious, though, and there was some room for other cleanups,
so I've reworked it. Once I run it through a couple more rounds of testing
I'll repost.

FYI, I'm able to easily test a variety of configs using a KVM guest and
this QEMU branch[*]. To use threads it's necessary to revert the last
QEMU patch and to hack KVM to set MPIDR.MT for the VCPUs.

Thanks,
drew

[*] https://github.com/rhdrjones/qemu/commits/virt-cpu-topology