[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <34f2279e49e04761acd273ec4e54e062@intel.com>
Date: Wed, 6 Apr 2022 22:38:30 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>,
"Borislav Petkov" <bp@...en8.de>
CC: "hpa@...or.com" <hpa@...or.com>,
Yazen Ghannam <yazen.ghannam@....com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>
Subject: RE: [RFC PATCH 3/5] x86/mce: Introduce a function pointer
mce_handle_storm
> Introduce a function pointer "mce_handle_storm". This function pointer
> does the vendor specific storm handling. In Intel it points to a routine
> to set different thresholds in IA32_MCi_CTL2.
Boris did some cleanups in machine check code to get rid of places
where function pointers were used. E.g.
cc466666ab09 x86/mce: Get rid of the ->quirk_no_way_out() indirect call
8121b8f947be x86/mce: Get rid of msr_ops
cbe1de162d82 x86/mce: Get rid of machine_check_vector
631adc7b0bba x86/mce: Get rid of the mce_severity function pointer
Was that to help with the "noinstr" cleanup? I'm not sure if that
would apply here (in which case mce_handle_storm would be
a regular function with a switch on "vendor".)
-Tony
Powered by blists - more mailing lists