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: <662a0c91-2f84-4091-b971-0219a1c8a3d9@zhaoxin.com>
Date: Fri, 20 Sep 2024 18:41:52 +0800
From: Tony W Wang-oc <TonyWWang-oc@...oxin.com>
To: Yazen Ghannam <yazen.ghannam@....com>
CC: <tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
	<dave.hansen@...ux.intel.com>, <x86@...nel.org>, <hpa@...or.com>,
	<tony.luck@...el.com>, <linux-kernel@...r.kernel.org>,
	<linux-edac@...r.kernel.org>, <CobeChen@...oxin.com>, <TimGuo@...oxin.com>,
	<LeoLiu-oc@...oxin.com>, Lyle Li <LyleLi@...oxin.com>
Subject: Re: [PATCH v3 1/3] x86/mce: Add centaur vendor to support Zhaoxin MCA



On 2024/9/19 21:55, Yazen Ghannam wrote:
> 
> On Wed, Sep 18, 2024 at 01:54:34PM +0800, Tony W Wang-oc wrote:
>> From: Lyle Li <LyleLi@...oxin.com>
>>
>> Zhaoxin consists of two vendors, X86_VENDOR_ZHAOXIN and
>> X86_VENDOR_CENTAUR, so add the centaur vendor to support
>> Zhaoxin MCA in mce/core.c and mce/intel.c.
>>
>> Signed-off-by: Lyle Li <LyleLi@...oxin.com>
>> Signed-off-by: Tony W Wang-oc <TonyWWang-oc@...oxin.com>
>> ---
>>   arch/x86/kernel/cpu/mce/core.c  | 12 +++++++++---
>>   arch/x86/kernel/cpu/mce/intel.c |  3 ++-
>>   2 files changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
>> index ad0623b65..7f79d900f 100644
>> --- a/arch/x86/kernel/cpu/mce/core.c
>> +++ b/arch/x86/kernel/cpu/mce/core.c
>> @@ -496,6 +496,7 @@ bool mce_usable_address(struct mce *m)
>>
>>        case X86_VENDOR_INTEL:
>>        case X86_VENDOR_ZHAOXIN:
>> +     case X86_VENDOR_CENTAUR:
>>                return intel_mce_usable_address(m);
>>
>>        default:
>> @@ -513,6 +514,7 @@ bool mce_is_memory_error(struct mce *m)
>>
>>        case X86_VENDOR_INTEL:
>>        case X86_VENDOR_ZHAOXIN:
>> +     case X86_VENDOR_CENTAUR:
>>                /*
>>                 * Intel SDM Volume 3B - 15.9.2 Compound Error Codes
>>                 *
>> @@ -1247,7 +1249,8 @@ static noinstr bool mce_check_crashing_cpu(void)
>>
>>                mcgstatus = __rdmsr(MSR_IA32_MCG_STATUS);
>>
>> -             if (boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) {
>> +             if (boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN ||
>> +                 boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR) {
>>                        if (mcgstatus & MCG_STATUS_LMCES)
>>                                return false;
>>                }
>> @@ -1521,7 +1524,8 @@ noinstr void do_machine_check(struct pt_regs *regs)
>>         * on Intel, Zhaoxin only.
>>         */
>>        if (m.cpuvendor == X86_VENDOR_INTEL ||
>> -         m.cpuvendor == X86_VENDOR_ZHAOXIN)
>> +         m.cpuvendor == X86_VENDOR_ZHAOXIN ||
>> +         m.cpuvendor == X86_VENDOR_CENTAUR)
>>                lmce = m.mcgstatus & MCG_STATUS_LMCES;
>>
>>        /*
>> @@ -2092,6 +2096,7 @@ static void __mcheck_cpu_clear_vendor(struct cpuinfo_x86 *c)
>>                break;
>>
>>        case X86_VENDOR_ZHAOXIN:
>> +     case X86_VENDOR_CENTAUR:
>>                mce_zhaoxin_feature_clear(c);
>>                break;
>>
>> @@ -2401,7 +2406,8 @@ static void vendor_disable_error_reporting(void)
>>        if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
>>            boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ||
>>            boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
>> -         boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN)
>> +         boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN ||
>> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR)
>>                return;
>>
>>        mce_disable_error_reporting();
> 
> At this point, should we even do this? It seems all major vendors want
> to *not* disable MCA_CTL after init.
> 
> This, and related functions, can be deleted. Unless there's a compelling
> reason to keep them.
> 

 From the current code implementation, your suggestion is reasonable.
Will delete the related functions in the next version.

Sincerely
TonyWWang-oc

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ