linux-kernel - RE: [PATCH] ACPI: processor_idle: Skip dummy wait for processors based on the Zen microarchitecture

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: <MN0PR12MB61013DC656891259F5D5FA96E24E9@MN0PR12MB6101.namprd12.prod.outlook.com>
Date:   Thu, 22 Sep 2022 21:38:11 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@....com>
To:     Dave Hansen <dave.hansen@...el.com>, Andreas Mohr <andi@...as.de>
CC:     "Nayak, K Prateek" <KPrateek.Nayak@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "lenb@...nel.org" <lenb@...nel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "puwen@...on.cn" <puwen@...on.cn>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "rui.zhang@...el.com" <rui.zhang@...el.com>,
        "gpiccoli@...lia.com" <gpiccoli@...lia.com>,
        "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
        "Narayan, Ananth" <Ananth.Narayan@....com>,
        "Shenoy, Gautham Ranjal" <gautham.shenoy@....com>,
        "Ong, Calvin" <Calvin.Ong@....com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>
Subject: RE: [PATCH] ACPI: processor_idle: Skip dummy wait for processors
 based on the Zen microarchitecture

[Public]



> -----Original Message-----
> From: Dave Hansen <dave.hansen@...el.com>
> Sent: Thursday, September 22, 2022 16:22
> To: Andreas Mohr <andi@...as.de>
> Cc: Nayak, K Prateek <KPrateek.Nayak@....com>; linux-
> kernel@...r.kernel.org; rafael@...nel.org; lenb@...nel.org; linux-
> acpi@...r.kernel.org; linux-pm@...r.kernel.org;
> dave.hansen@...ux.intel.com; bp@...en8.de; tglx@...utronix.de;
> puwen@...on.cn; Limonciello, Mario <Mario.Limonciello@....com>;
> peterz@...radead.org; rui.zhang@...el.com; gpiccoli@...lia.com;
> daniel.lezcano@...aro.org; Narayan, Ananth <Ananth.Narayan@....com>;
> Shenoy, Gautham Ranjal <gautham.shenoy@....com>; Ong, Calvin
> <Calvin.Ong@....com>; stable@...r.kernel.org;
> regressions@...ts.linux.dev
> Subject: Re: [PATCH] ACPI: processor_idle: Skip dummy wait for processors
> based on the Zen microarchitecture
> 
> On 9/22/22 13:10, Andreas Mohr wrote:
> >   (- but then what about other more modern chipsets?)
> >
> > --> we need to achieve (hopefully sufficiently precisely) a solution which
> > takes into account Zen3 STPCLK# improvements while
> > preserving "accepted" behaviour/requirements on *all* STPCLK#-
> hampered chipsets
> > ("STPCLK# I/O wait is default/traditional handling"?).
> 
> Ideally, sure.  But, we're talking about theoretically regressing the
> idle behavior of some indeterminate set of old systems, the majority of
> which are sitting in a puddle of capacitor goo at the bottom of a
> landfill right now.  This is far from an ideal situation.
> 
> FWIW, I'd much rather do something like
> 
> 	if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
> 	    (boot_cpu_data.x86_model >= 0xF))
> 		return;
> 
> 	inl(slow_whatever);
> 
> than a Zen check.  AMD has, as far as I know, been a lot more sequential
> and sane about model numbers than Intel, and there are some AMD model
> number range checks in the codebase today.
> 
> A check like this would also be _relatively_ future-proof in the case
> that X86_FEATURE_ZEN stops getting set on future AMD CPUs.  That's a lot
> more likely than AMD going and reusing a <0xF model.

If you're going to use a family check instead it should be 0x17 or newer.
(c->x86 >= 0x17)

That does match what's used to set X86_FEATURE_ZEN at least then right now too.