linux-kernel - Re: [PATCH 2/2] x86/mce: Add support for Extended Physical Address MCA changes

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: <1c21d3c5-8a5a-31cf-6d84-0905a0c508da@amd.com>
Date:   Thu, 10 Jun 2021 22:36:44 -0500
From:   Smita Koralahalli Channabasappa <skoralah@....com>
To:     Borislav Petkov <bp@...en8.de>,
        Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        linux-edac@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
        Yazen Ghannam <yazen.ghannam@....com>,
        Muralidhara M K <muralimk@....com>,
        Akshay Gupta <Akshay.Gupta@....com>,
        Youquan Song <youquan.song@...el.com>,
        Zhen Lei <thunder.leizhen@...wei.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 2/2] x86/mce: Add support for Extended Physical Address
 MCA changes

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

>