Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Message-ID: <4ce89a5e-96f8-4939-b86e-f65c16f4bd4e@intel.com>
Date:   Thu, 14 Dec 2023 00:57:51 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: x86/mce: Is mce_is_memory_error() incorrect for Intel?
To:     <x86@kernel.org>, Borislav Petkov <bp@alien8.de>,
        Tony Luck <tony.luck@intel.com>
CC:     Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H . Peter Anvin" <hpa@zytor.com>,
        "Yazen Ghannam" <yazen.ghannam@amd.com>,
        Arnd Bergmann <arnd@arndb.de>, <linux-kernel@vger.kernel.org>,
        <linux-edac@vger.kernel.org>
References: <20231206013846.1859347-1-sohil.mehta@intel.com>
Content-Language: en-US
From:   Sohil Mehta <sohil.mehta@intel.com>
In-Reply-To: <20231206013846.1859347-1-sohil.mehta@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SXp0VVY3WlFQL3FjOUljeFl4cmRqdEFDTEhndE9HNXRlaXZuOXlYL2ZyWVFY?=
 =?utf-8?B?RDVCNkoxVzZ4WW9uU1JwYUpjamQ0cEs4am1XdjBEV1Q3Mk0raHF6SzhnOXh6?=
 =?utf-8?B?cCtPS1E3eDIwcnRHdWl4SStzcEEyVWlBUVd1bDBPSytnNFZwOWdFeXBCWjE1?=
 =?utf-8?B?ME80TC9UeDBIWURRUkJubVF3WVNjR1lUSisxWVZRMzMxVU5zakcwVVNRd2pZ?=
 =?utf-8?B?YzdPRVRZNERkR1NialdxVUNWaUJZSXNETVkwQXVpSVpYdmluL05UNTc5WE42?=
 =?utf-8?B?d09vYU91U0ErbEFEVG1Ea0lOK3J3NFJITlRjNFVMSDRpZjFqNTlmSEhNMkFk?=
 =?utf-8?B?cGFKRWZmdnR3VFhCaVQ0bEoxUEhXWXVUSVJ0MHluQWFobi9PWXFkaUo3UFJ6?=
 =?utf-8?B?WUx3ZEg1YS9CYWExNTZxM2w3N1hEdUZDV0Rub2FHeDZPdEtIMGtxUDBOYnEx?=
 =?utf-8?B?Mm1icXJhVG5zOHNXS0JiemVMeXlKZ29uZXM1aHBzK1Jhb09GR0hwVVVsOE1Q?=
 =?utf-8?B?a2tpeG43Z3NuMXd0d0o4WjJ3eWl2aGNBTXdUWUo3c29QRDN5MFdiUXVMRi9K?=
 =?utf-8?B?OG1QYU9Sc2VlU0NUVVgvR0lad2dGeFdOa1Z0MEVNVEdjdng4YVZHU2hEeDY5?=
 =?utf-8?B?YW9IcFI1N09uV0hHYkRVVjlpRnVOeTcyTHpKeTlyVHAwL2FNWm55K0U5RGxK?=
 =?utf-8?B?YVJkTDRBNzNhSVdMMnlscVhvMm51UXlsZ01OeDk2TzYrVkM5T2tOcE1zckM5?=
 =?utf-8?B?UjZINVhwWXZnS2F5SWZhUXlQU2pJakx0NVF5by9hWHpTTVlLUWEvRzBVRTJi?=
 =?utf-8?B?MEVRbEdJbS82eUFsdkdBRi9TOEQvUDlISUxTbHZJMk9zNFkwV0RHWi95MUo1?=
 =?utf-8?B?Q1hvb3hVZXk2TkU3aG82MEhLUlpZbWwrRXRMODJ2U1VGOERJdWRTdlVVSlFz?=
 =?utf-8?B?NFJSWk1weGpVTTRZNmVKbDNlNUljRkRkTHNWdTd4TUlRUjVGNFA4NnlFMmtQ?=
 =?utf-8?B?aEo0ZHhZMHdFNUlwTEVrdjR6cERZbklicGprZXhIYXQ3elZVT1c1YUFncU01?=
 =?utf-8?B?eERvbi9ReTRpV2VZNVZVUXZENlFFTEJZcFVBUlU5bXZKckVTdy9JUUt6QkhD?=
 =?utf-8?B?TDEyL1hTK1hSRlQveVRYREtzTTNrSUhvMkdvWHZ2Mm00b0Qxamd2UUdoNkxm?=
 =?utf-8?B?Uk9CK2dwOWZXSHFqT3hHUnFEMko4aWhvVXhyTGl0NGxvUWd4U28xNWlRRnBS?=
 =?utf-8?B?YUxoUTBxaWFJU1J0QksybTgyZm5CMjJQZFd3UU16Q05vWnZiK0Q4TG53Zkc4?=
 =?utf-8?B?bWhXRmRxQTJUTWNoMTd5RU5FY1ZHYmJjWmxVWlh6aEl1dlZKK0UxK3RHSGli?=
 =?utf-8?B?RVRLQ1U5UUN2dk5mYzFNcHBVN29iejF4emd0R3FodWZmcDRUOXk2RDJOZkRl?=
 =?utf-8?B?c0RMczluUXVRVk85NXpJZTZYMjk5OEwrUnAwLy9ndjBGYUtlUWZFVUxWeEhs?=
 =?utf-8?B?RjQyVXEwNWd5L2RFeHozWHJsWUx6NFhMYUY1eUZscm1XMnhJRWVadHlURU9w?=
 =?utf-8?B?QlBOaFUyNUZDUzh4NktQcXJodUxzRzNiV1RYMnRSeXpucGlicWI4VUZDVXkv?=
 =?utf-8?B?OEMra3ZUb3pEdE1lcjNpWktqTEVxTHZJRVRMRU9pcUd5WE5uaFIyWlBHTERk?=
 =?utf-8?B?WWRQZ0Z4VTJ3MkR2RXNHN0xUWVRJNkNaaFVmNmwyS2tUK2ZObzZ5aWRkeGhj?=
 =?utf-8?B?elFyZDJlZ01hNy9HK0F3T0NXWXFaMm9OdDFDSDZmTGYxY1ZYTDRaMmRCVm0y?=
 =?utf-8?B?Um91UHdTY0k4WUpjRWNldHdpTzZ0VXUySUpJVE1IbjdUOFc5R3BZenZ0SS9E?=
 =?utf-8?B?Ryt0Q3AzUXVuZ3hYS01veE1SNk0rVHdvK1M0cmpEc2JnVHVmNFVxTmdGZFBQ?=
 =?utf-8?B?aHBWVFhzL2p4NFhFNXVFbGNlRDcrY080TXh1RllWTDRERkVReFQwK01zVGJo?=
 =?utf-8?B?RGZJR051YXJPWEdFL3Zxa0YwL2xYbThMSmExSklzQkg1RUc1L0FPTmdiTk16?=
 =?utf-8?B?QmZrVEVWM1gvWEJxRmhwQ3ZhMHNydTh5TFhNWWZ1WkxiZVRFKy9aWkw3RERR?=
 =?utf-8?B?blkzcUZGWEd4S3hIeTZqc1dHMEozZjI5V3VtS1RBemdDUnRqQjFUSysyMEtE?=
 =?utf-8?B?WlE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 566c217a-9cef-4d3b-d037-08dbfc119e70
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3320.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2023 19:28:01.1300
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 6Z89JdCK/jgqQH4DWVIgW2uLQ9jEro+sLaqkPqRtIZwdxUDr/+EnCorg6xg3GzDvsasA/8B95RRs5MahlfIrfw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7291
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Wed, 13 Dec 2023 11:28:30 -0800 (PST)

On 12/6/2023 7:08 AM, Sohil Mehta wrote:

In an effort to rewrite the below Intel specific comment in
mce_is_memory_error(), I think I may have found an issue. It would be
really helpful if someone can help check the analysis below.

> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 7b397370b4d6..d42122b1afea 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -482,7 +482,8 @@ bool mce_is_memory_error(struct mce *m)
>  	case X86_VENDOR_INTEL:
>  	case X86_VENDOR_ZHAOXIN:
>  		/*
> -		 * Intel SDM Volume 3B - 15.9.2 Compound Error Codes
> +		 * Intel SDM: Machine-Check Architecture -> "Compound Error
> +		 * Codes"
>  		 *
>  		 * Bit 7 of the MCACOD field of IA32_MCi_STATUS is used for
>  		 * indicating a memory error. Bit 8 is used for indicating a


The full comment reads as follows:

* Bit 7 of the MCACOD field of IA32_MCi_STATUS is used for
* indicating a memory error. Bit 8 is used for indicating a
* cache hierarchy error. The combination of bit 2 and bit 3
* is used for indicating a `generic' cache hierarchy error
* But we can't just blindly check the above bits, because if
* bit 11 is set, then it is a bus/interconnect error - and
* either way the above bits just gives more detail on what
* bus/interconnect error happened. Note that bit 12 can be
* ignored, as it's the "filter" bit.
*/

return (m->status & 0xef80) == BIT(7) ||  ---> Memory Controller Errors
	(m->status & 0xef00) == BIT(8) || ---> Cache Hierarchy Errors
	(m->status & 0xeffc) == 0xc;	  ---> Generic Cache Hierarchy

The code tries to identify the memory and cache errors by masking the
status and then comparing based on the bit encodings below. But it seems
to be missing the "Extended Memory Errors" encoding which may have been
added after the original code was written.

Type 				Form
----				----
Generic Cache Hierarchy 	000F 0000 0000 11LL
TLB Errors			000F 0000 0001 TTLL
Memory Controller Errors	000F 0000 1MMM CCCC
Cache Hierarchy Errors		000F 0001 RRRR TTLL
Extended Memory Errors		000F 0010 1MMM CCCC
Bus and Interconnect Errors	000F 1PPT RRRR IILL

I am not sure what are the practical implications of getting
mce_is_memory_error() wrong. (This issue is completely theoretical right
now.) Any insights?

A couple of other points:

- The code seems ripe for a rewrite to be rid of the magic masks and bit
comparisons. I am thinking of doing that in a separate patch along side
of rewriting the comment. Would that be useful even if no issue exists?

- Relying on these bit encodings seems problematic in the long run with
the possibility of more things that could always be added. Is there a
better way to do it?

Sohil