Messages in this thread | | | Subject | Re: [PATCH 2/2] x86/mce: Add support for Extended Physical Address MCA changes | From | Smita Koralahalli Channabasappa <> | Date | Thu, 10 Jun 2021 22:36:44 -0500 |
| |
On 6/10/21 6:55 AM, Borislav Petkov wrote:
> On Tue, Jun 08, 2021 at 05:10:12PM -0500, Smita Koralahalli wrote: >> diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c >> index f71435e53cdb..480a497877e2 100644 >> --- a/arch/x86/kernel/cpu/mce/amd.c >> +++ b/arch/x86/kernel/cpu/mce/amd.c >> @@ -204,6 +204,12 @@ EXPORT_SYMBOL_GPL(smca_banks); >> #define MAX_MCATYPE_NAME_LEN 30 >> static char buf_mcatype[MAX_MCATYPE_NAME_LEN]; >> >> +struct smca_config { >> + __u64 lsb_in_status : 1, >> + __reserved_0 : 63; >> +}; >> +static DEFINE_PER_CPU_READ_MOSTLY(struct smca_config[MAX_NR_BANKS], smca_cfg); > Per CPU and per bank, huh? For a single bit? > > Even if we have > > static DEFINE_PER_CPU_READ_MOSTLY(struct mce_bank[MAX_NR_BANKS], mce_banks_array); > > already?
The idea of defining a new struct was to keep SMCA specific stuff separate. Thought, it would be costly to include in existing struct mce_bank[] as it will be unnecessarily defined for each cpu and each bank across all vendors even if they aren't using it and would be a problem if they are constraint on resource and space.
Also, in the future we can use this newly defined struct smca_config[] to cache other MCA_CONFIG feature bits for different use cases if they are per bank and per cpu.
I understand its unnecessary overhead atleast now, to just have a new struct per cpu per bank for a single bit in which case I can refrain defining a new one and include it in the existing struct.
Let me know what do you think?
Thanks, Smita
>
| |