Received-SPF: pass (google.com: domain of linux-kernel+bounces-64915-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Wed, 14 Feb 2024 10:06:30 +0100
From: Borislav Petkov <bp@alien8.de>
To: Yazen Ghannam <yazen.ghannam@amd.com>
Cc: tony.luck@intel.com, linux-edac@vger.kernel.org,
	linux-kernel@vger.kernel.org, avadhut.naik@amd.com,
	john.allen@amd.com, muralidhara.mk@amd.com,
	naveenkrishna.chatradhi@amd.com, sathyapriya.k@amd.com
Subject: Re: [PATCH 2/2] RAS: Introduce the FRU Memory Poison Manager
Message-ID: <20240214090630.GAZcyClhFloQfHEqrC@fat_crate.local>
References: <20240214033516.1344948-1-yazen.ghannam@amd.com>
 <20240214033516.1344948-3-yazen.ghannam@amd.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240214033516.1344948-3-yazen.ghannam@amd.com>

On Tue, Feb 13, 2024 at 09:35:16PM -0600, Yazen Ghannam wrote:
> Memory errors are an expected occurrence on systems with high memory
> density. Generally, errors within a small number of unique physical
> locations is acceptable, based on manufacturer and/or admin policy.
> During run time, memory with errors may be retired so it is no longer
> used by the system. This is done in the kernel memory manager, and the
> effect will remain until the system is restarted.
> 
> If a memory location is consistently faulty, then the same run time
> error handling may occur in the next reboot cycle. Running jobs may be
> terminated due to previously known bad memory. This could be prevented
> if information from the previous boot was not lost.
> 
> Some add-in cards with driver-managed memory have on-board persistent
> storage. Their driver may save memory error information to the
> persistent storage during run time. The information may then be restored
> after reset, and known bad memory may be retired before use. A running
> log of bad memory locations is kept across multiple resets.

Too many "may"s above, please tone them down.

> A similar solution is desirable for CPUs. However, this solution should

GPUs you mean?

> leverage industry-standard components, as much as possible, rather than
> a bespoke platform driver.
> 
> Two components are needed: a record format and a persistent storage
> interface.
> 
> A UEFI CPER "FRU Memory Poison Section" is being proposed, along with a
> "Memory Poison Descriptor", to use for this purpose. These new structures
> are minimal, saving space on limited non-volatile memory, and extensible.
> 
> CPER-aware persistent storage interfaces, like ACPI ERST and EFI Runtime
> Variables, can be used. A new interface is not required.

I don't think stuff which is being proposed belongs here.

> Implement a new module to manage the record formats on persistent
> storage. Use the requirements for an AMD MI300-based system to start.
> Vendor- and platform-specific details can be abstracted later as needed.

This is a big diff so I'm splitting mails.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette