linux-kernel - Re: [PATCH v6 02/15] x86/mce: Define BSP-only init

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: <861a0703-2adc-4e8c-86e5-c22192759e80@suse.com>
Date: Wed, 10 Sep 2025 17:28:43 +0300
From: Nikolay Borisov <nik.borisov@...e.com>
To: Yazen Ghannam <yazen.ghannam@....com>
Cc: x86@...nel.org, Tony Luck <tony.luck@...el.com>,
 "Rafael J. Wysocki" <rafael@...nel.org>, linux-kernel@...r.kernel.org,
 linux-edac@...r.kernel.org, Smita.KoralahalliChannabasappa@....com,
 Qiuxu Zhuo <qiuxu.zhuo@...el.com>, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v6 02/15] x86/mce: Define BSP-only init



On 10.09.25 г. 16:53 ч., Yazen Ghannam wrote:
> On Wed, Sep 10, 2025 at 02:47:16PM +0300, Nikolay Borisov wrote:
>>
>>
>> On 9/8/25 18:40, Yazen Ghannam wrote:
>>> Currently, MCA initialization is executed identically on each CPU as
>>> they are brought online. However, a number of MCA initialization tasks
>>> only need to be done once.
>>>
>>> Define a function to collect all 'global' init tasks and call this from
>>> the BSP only. Start with CPU features.
>>>
>>> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@...el.com>
>>> Tested-by: Tony Luck <tony.luck@...el.com>
>>> Reviewed-by: Tony Luck <tony.luck@...el.com>
>>> Signed-off-by: Yazen Ghannam <yazen.ghannam@....com>
>>
>> <snip>
>>
>>> @@ -2240,6 +2233,27 @@ DEFINE_IDTENTRY_RAW(exc_machine_check)
>>>    }
>>>    #endif
>>> +void mca_bsp_init(struct cpuinfo_x86 *c)
>>> +{
>>> +	u64 cap;
>>> +
>>> +	if (!mce_available(c))
>>> +		return;
>>> +
>>> +	mce_flags.overflow_recov = cpu_feature_enabled(X86_FEATURE_OVERFLOW_RECOV);
>>> +	mce_flags.succor	 = cpu_feature_enabled(X86_FEATURE_SUCCOR);
>>> +	mce_flags.smca		 = cpu_feature_enabled(X86_FEATURE_SMCA);
>>> +
>>> +	rdmsrq(MSR_IA32_MCG_CAP, cap);
>>> +
>>> +	/* Use accurate RIP reporting if available. */
>>> +	if ((cap & MCG_EXT_P) && MCG_EXT_CNT(cap) >= 9)
>>> +		mca_cfg.rip_msr = MSR_IA32_MCG_EIP;
>>> +
>>> +	if (cap & MCG_SER_P)
>>> +		mca_cfg.ser = 1;
>>> +}
>>> +
>>
>>
>> LGTM
>>
>> Reviewed-by: Nikolay Borisov <nik.borisov@...e.com>
> 
> Thanks Nikokay for the reviews.
> 
>>
>> nit: One question though for those CPUs which consist of P+E cores, is it
>> mandated that both types of cores will have identical MCE architecture, I
>> assume the x86 world will be a lot more unified than Arm's big.LITTLE ?
>>
> 
> I think technically no, they won't be mandated to be identical. We already
> have per-CPU feature bits, registers, etc. And in Scalable MCA there are
> also per-bank config bits.
> 
> However, this doesn't mean we will have different MCE features between
> CPUs in a system just yet. The architects do try to make things flexible
> and scalable just in case there is a need in the future.
> 
> We can code to the architectures and be *mostly* future-proof. But it's
> not guaranteed to be without bugs. And it's not guaranteed that every
> possible case will be used.
> 
> Do you have any concerns or see any issues with the code today in this
> area? Maybe you're thinking we should have per-CPU config for feature
> bits? If so, I agree but we don't have a real need today AFAIK.

Yes, for example in your current code you assume that whatever the value 
of MSR_IA32_MCG_CAP w.r.t MCG_EXT_P or MCG_SER_P it will be identical 
for all CPUs. That might be fine, but what if, in the future, we end up 
with machines where MCG_CAP will have different values for different 
CPU's/cores.

Or that in a system we can end up with cpu's which have different 
X86_FEATURE_SMCA value.

OTOH, you are right that when the time comes we can worry about this 
since there can possibly be infinite number of possible scenarios.

> 
> Maybe others can comment too.
> 
> Thanks,
> Yazen