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:   Sat, 12 Dec 2020 08:36:48 +0900
From:   Punit Agrawal <punitagrawal@...il.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Wei Huang <whuang2@....com>, rjw@...ysocki.net, wei.huang2@....com,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        x86@...nel.org
Subject: Re: [RFC PATCH 2/4] cpufreq: acpi-cpufreq: Add processor to the
 ignore PSD override list

Borislav Petkov <bp@...en8.de> writes:

> On Wed, Dec 09, 2020 at 08:21:48AM +0900, Punit Agrawal wrote:
>> According to the commit log, acd316248205 seems to be only targeted at
>> powernow-K8 -
>
> No, it is not targeted at powernow-k8 - acpi-cpufreq.c is what is used
> on AMD hw. He means to make acpi-cpufreq's behavior consistent with
> powernow-k8.

So "powernow-k8" is not a cpu but a cpufreq driver. That doesn't change
the fact that the patch causes all AMD systems using acpi-cpufreq to
ignore processor frequency groupings and treat each processor to be an
in independent frequency domain from cpufreq's point of view.

>> But if that is not available, the only way we have is to include
>> systems that have been verified to not need the override
>
> You have verified exactly *one* system - yours. Or are you sure that
> *all* family 0x17, model 0x60, stepping 0x1 machines don't need the
> override?

Unfortunately, I only have access to one system with that F/M/S.

Since posting the non-RFC patches, I was able to inspect the ACPI tables
for more CPUs -

Family: 0x17h, Model: 0x71h (Ryzen 3950X)
Family: 0x17h, Model: 0x18h (Ryzen 3500u)

To me it suggests, that there are likely more systems from the family
that show the characteristic described below.

> Also, you still haven't explained what you're trying to fix here.

All the CPUs here are multi-threaded with 2 threads per core. The _PSD
for the system describes the cores as having a coupling that consist of
a frequency domain per core that contains both the threads. The firmware
description makes sense and seems to accurately describe the hardware
topology.

In all these systems, the override causes this topology information to
be ignored - treating each core to be a separate domain. The proposed
patch removes the override so that _PSD is taken into account.

Powered by blists - more mailing lists