[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b954a96-1034-467d-a5dc-3d3f7bc112a1@intel.com>
Date: Tue, 11 Feb 2025 12:26:48 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Sohil Mehta <sohil.mehta@...el.com>, x86@...nel.org,
Dave Hansen <dave.hansen@...ux.intel.com>, Tony Luck <tony.luck@...el.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Kan Liang <kan.liang@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>, "H . Peter Anvin" <hpa@...or.com>,
"Rafael J . Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
Andy Lutomirski <luto@...nel.org>, Viresh Kumar <viresh.kumar@...aro.org>,
Fenghua Yu <fenghua.yu@...el.com>, Jean Delvare <jdelvare@...e.com>,
Guenter Roeck <linux@...ck-us.net>, Zhang Rui <rui.zhang@...el.com>,
Andrew Cooper <andrew.cooper3@...rix.com>,
David Laight <david.laight.linux@...il.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-pm@...r.kernel.org,
linux-hwmon@...r.kernel.org
Subject: Re: [PATCH v2 04/17] x86/cpu/intel: Fix the movsl alignment
preference for extended Families
We should really rename intel_workarounds() to make it more clear that
it's 32-bit only. But I digress...
On 2/11/25 11:43, Sohil Mehta wrote:
> The alignment preference for 32-bit movsl based bulk memory move has
> been 8-byte for a long time. However this preference is only set for
> Family 6 and 15 processors.
>
> Extend the preference to upcoming Family numbers 18 and 19 to maintain
> legacy behavior. Also, use a VFM based check instead of switching based
> on Family numbers. Refresh the comment to reflect the new check.
"Legacy behavior" is not important here. If anyone is running 32-bit
kernel binaries on their brand new CPUs they (as far as I know) have a
few screws loose. They don't care about performance or security and we
shouldn't care _for_ them.
If the code yielded the "wrong" movsl_mask.mask for 18/19, it wouldn't
matter one bit.
The thing that _does_ matter is someone auditing to figure out whether
the code comprehends families>15 or whether it would break in horrible
ways. The new check is shorter and it's more obvious that it will work
forever.
Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>
Powered by blists - more mailing lists