lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 28 Jun 2018 13:57:48 +0200
From:   Andrew Jones <drjones@...hat.com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     Shunyong Yang <shunyong.yang@...-semitech.com>,
        catalin.marinas@....com, will.deacon@....com,
        linux-kernel@...r.kernel.org, jeremy.linton@....com,
        Joey Zheng <yu.zheng@...-semitech.com>
Subject: Re: [RFC PATCH] arm64: topology: Map PPTT node offset to logic
 physical package id

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ