linux-kernel - Re: [PATCH v2] arch_topology: Support SMT control on arm64

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]

Message-ID: <20231011103303.00002d8f@Huawei.com>
Date:   Wed, 11 Oct 2023 10:33:03 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     Yicong Yang <yangyicong@...wei.com>, <yangyicong@...ilicon.com>,
        <catalin.marinas@....com>, <will@...nel.org>,
        <sudeep.holla@....com>, <linux-arm-kernel@...ts.infradead.org>,
        <dietmar.eggemann@....com>, <rafael@...nel.org>,
        <prime.zeng@...ilicon.com>, <linuxarm@...wei.com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] arch_topology: Support SMT control on arm64

On Tue, 10 Oct 2023 16:08:25 +0200
Greg KH <gregkh@...uxfoundation.org> wrote:

> On Tue, Oct 10, 2023 at 09:10:48PM +0800, Yicong Yang wrote:
> > On 2023/10/10 20:33, Greg KH wrote:  
> > > On Tue, Oct 10, 2023 at 07:53:35PM +0800, Yicong Yang wrote:  
> > >> From: Yicong Yang <yangyicong@...ilicon.com>
> > >>
> > >> The core CPU control framework supports runtime SMT control which
> > >> is not yet supported on arm64. Besides the general vulnerabilities
> > >> concerns we want this runtime control on our arm64 server for:  
> > > 
> > > But shouldn't this be part of UEFI?  Why manually try to determine this
> > > at powerup in Linux?  
> > 
> > We can disable/enable SMT by UEFI, but it lacks of flexibility. With runtime
> > support we can disable/enable on demand, rather than disable/enable all the time.
> > In our case, mainly for the below 2 reasons in the commit.  
> 
> Runtime is fine, it's the initial detection that I have questions about,
> see below.
> 
> > > And again, why is this not an issue on the current platforms that
> > > already support CONFIG_HOTPLUG_SMT?  What makes ARM64 so broken it
> > > requires this manual intervention?
> > >   
> > 
> > Currently I see x86 and powerpc supports CONFIG_HOTPLUG_SMT on the mainline.
> > For x86 they build the topology and detects the SMT suppport in the arch
> > code, seems they can directly get the SMT number by reading the system
> > register, refers to arch/x86/kernel/cpu/common.c:detect_ht_early(). For
> > powerpc I see they are reading the threads number from the firmware(OF)
> > and assuming all the SMT have the same thread number, refer to
> > arch/powerpc/kernel/setup-common.c:smp_setup_cpu_maps(). Please corrects
> > me if there's mistakes.
> > 
> > Back to arm64, there's no system registers to directly indicate the thread
> > numbers of each SMT in the system like x86, nor do we have the information
> > from the firmware (OF/ACPI).  
> 
> UEFI/ACPI should be showing you this information, as that's how x86 gets
> the information, right?  If not, it needs to be added as part of the
> specification.
> 
> > I cannot assume all the physical cores have
> > the same thread number, since we may have SMT cores and non-SMT cores on
> > heterogeneous platform. We can only know the SMT information after
> > parsing the firmware information.  
> 
> Ugh, heterogeneous platforms, why???  Anyway, I didn't think about that,
> but even then, the firmware should be giving you this information in a
> standard way, otherwise it's not following the UEFI/ACPI specification
> from what I can tell.

It can be established from ACPI PPTT, but it's pretty indirect.  You'd need
to search all leaf nodes of the tree and find "Processor Hierarchy Nodes
tagged as "Processor is a thread" then walk up from those find common
ancestors.  So ultimately I think you end up doing some form of multiple
pass. I'm not sure it ends up simpler than what yangyicong had here.

There may be better algorithms than the simple nested loop here though
with better scalability.

Jonathan






> 
> thanks,
> 
> greg k-h