[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB6083C60DA6D92C629C958B7FFCEA2@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Tue, 21 May 2024 15:21:08 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Dave
Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H.
Peter Anvin" <hpa@...or.com>, "Peter Zijlstra (Intel)"
<peterz@...radead.org>, Uros Bizjak <ubizjak@...il.com>, "Edgecombe, Rick P"
<rick.p.edgecombe@...el.com>, Arnd Bergmann <arnd@...db.de>, Mateusz Guzik
<mjguzik@...il.com>, Thomas Renninger <trenn@...e.de>, Andi Kleen
<ak@...ux.intel.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "patches@...ts.linux.dev"
<patches@...ts.linux.dev>
Subject: RE: [PATCH v6 00/49] New Intel CPUID families
>> - Please consider patches 0001 & 0002 as urgent to fix a regression.
>>
>> 1 and 2?
>
> Only 2 I think...
Patch 2 fixes the existing regression. But if you apply just that patch it
will create a new regression. Patch 1 fixes the place where someone
isn't using the X86_MATCH macros. Just open coding:
{ .vendor = X86_VENDOR_INTEL, .family = 6, .model = INTEL_FAM6_SKYLAKE_X },
so they don't set .flags Patch 2 changes x86_match_cpu() to just use flags as the
end marker for the array:
for (m = match; m->flags & X86_CPU_ID_FLAG_ENTRY_VALID; m++) {
-Tony
Powered by blists - more mailing lists