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

[Greg KH]

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@xxxxxxxxxxxxx>
> >>
> >> 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.

thanks,

greg k-h