Received-SPF: pass (google.com: domain of linux-kernel+bounces-203861-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <d4079e9f-07cf-4893-9fc5-5d319b592aa5@zhaoxin.com>
Date: Thu, 6 Jun 2024 16:44:38 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/hpet: Read HPET directly if panic in progress
To: "Luck, Tony" <tony.luck@intel.com>, Borislav Petkov <bp@alien8.de>
CC: Thomas Gleixner <tglx@linutronix.de>, Linus Torvalds
	<torvalds@linux-foundation.org>, "Hansen, Dave" <dave.hansen@intel.com>,
	"mingo@redhat.com" <mingo@redhat.com>, "dave.hansen@linux.intel.com"
	<dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>, "keescook@chromium.org"
	<keescook@chromium.org>, "gpiccoli@igalia.com" <gpiccoli@igalia.com>,
	"mat.jonczyk@o2.pl" <mat.jonczyk@o2.pl>, "rdunlap@infradead.org"
	<rdunlap@infradead.org>, "alexandre.belloni@bootlin.com"
	<alexandre.belloni@bootlin.com>, "mario.limonciello@amd.com"
	<mario.limonciello@amd.com>, "yaolu@kylinos.cn" <yaolu@kylinos.cn>,
	"bhelgaas@google.com" <bhelgaas@google.com>, "justinstitt@google.com"
	<justinstitt@google.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-hardening@vger.kernel.org"
	<linux-hardening@vger.kernel.org>, "CobeChen@zhaoxin.com"
	<CobeChen@zhaoxin.com>, "TimGuo@zhaoxin.com" <TimGuo@zhaoxin.com>,
	"LeoLiu-oc@zhaoxin.com" <LeoLiu-oc@zhaoxin.com>
References: <20240528063836.5248-1-TonyWWang-oc@zhaoxin.com>
 <50fc1bd3-909e-41c4-a991-9d81e32ef92c@intel.com> <87wmnda8mc.ffs@tglx>
 <CAHk-=wgMoeOTL1V3wTO=o=U1OXn7xF8OWv2hB9NF9Z=G4KotfQ@mail.gmail.com>
 <87le3t9i8c.ffs@tglx> <0aff3f62-a8a5-4358-ae3f-2ded339aface@zhaoxin.com>
 <20240605093609.GCZmAxidNIBP5bkDcX@fat_crate.local>
 <e4f307dd-3264-45f6-82eb-0102f7fb99d7@zhaoxin.com>
 <20240605113323.GFZmBNA7ec2s191_2w@fat_crate.local>
 <46741fad-425c-4ed2-97be-3f2679da63eb@zhaoxin.com>
 <SJ1PR11MB60833ACD1E6C946F72C58736FCF92@SJ1PR11MB6083.namprd11.prod.outlook.com>
Content-Language: en-US
From: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
In-Reply-To: <SJ1PR11MB60833ACD1E6C946F72C58736FCF92@SJ1PR11MB6083.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


On 2024/6/5 23:51, Luck, Tony wrote:
> 
> 
> [这封邮件来自外部发件人 谨防风险]
> 
>>> Which types exactly do you mean when you're looking at the severities[]
>>> array in severity.c?
>>>
>>> And what scenario are you talking about?
>>>
>>> To get an #MC exception and detect only UCNA/SRAO errors? Can that even
>>> happen on any hardware?
>>>
>>
>> Yes, I mean an #MC exception happened and detect only like SRAO errors
>> like below:
>>
>>           MCESEV(
>>                   AO, "Action optional: memory scrubbing error",
>>                   SER, MASK(MCI_UC_AR|MCACOD_SCRUBMSK,
>> MCI_STATUS_UC|MCACOD_SCRUB)
>>                   ),
>>           MCESEV(
>>                   AO, "Action optional: last level cache writeback error",
>>                   SER, MASK(MCI_UC_AR|MCACOD, MCI_STATUS_UC|MCACOD_L3WB)
>>                   ),
>>
>> I think these errors are actually encountered on some platforms that
>> support these type of errors report to the #MC.
> 
> Intel servers from Nehalem through Cascade Lake reported memory controller
> patrol scrub uncorrected error with #MC and SRAO signature.
> 
> Icelake and newer use CMCI with a UCNA signature.
> 

I have a question, does Intel use #MC to report UCNA errors?

Sincerely
TonyWWang-oc