Received-SPF: pass (google.com: domain of linux-kernel+bounces-65330-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <9a82e9af-24c0-4277-b4d0-a708bba2cc88@amd.com>
Date: Wed, 14 Feb 2024 09:21:45 -0500
User-Agent: Mozilla Thunderbird
Cc: yazen.ghannam@amd.com, 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
Content-Language: en-US
To: Borislav Petkov <bp@alien8.de>
References: <20240214033516.1344948-1-yazen.ghannam@amd.com>
 <20240214033516.1344948-3-yazen.ghannam@amd.com>
 <20240214090630.GAZcyClhFloQfHEqrC@fat_crate.local>
From: Yazen Ghannam <yazen.ghannam@amd.com>
In-Reply-To: <20240214090630.GAZcyClhFloQfHEqrC@fat_crate.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?aWp6eklvSWZwVS8xWGluR3BzRUVjVmxLTW1udFFZZndldllqa0daWWx1Ymhr?=
 =?utf-8?B?T0JDSEdvN0VLUEE3VTFySGNFZHgyVnJuc1ZqYTRweXZXTm9sUEQvSTdUVHhl?=
 =?utf-8?B?SXUvMDJUekJOK0I1cGl5bzRYdzdVUVN3S0J0eXM4dHZzVGY5TE5sQU5DNFB3?=
 =?utf-8?B?YXp0eXd6UkRidDdrL2Z4UENYUEVia0VmNnVORy81UW15Sk5OSjROZHhIMUNs?=
 =?utf-8?B?ak5PcUpCdEdrMDl6WFlOYm9KZXlOK3BUZ1ZDU3NlNTFsWlh3dnZwV2N6UDk2?=
 =?utf-8?B?Si9ZdnNneFUvVnJUVzZ4VEFpRlo3SC9tN1FUZnkzR3ZnaG1nRnFuR1RkQWFW?=
 =?utf-8?B?Y0VWZWdNbEJhWmx3WTdMaDVkOHUyL2ErR05ZN3FOblBLWUFhWHVqbXZ3Vkkw?=
 =?utf-8?B?SWR0dzYrWjdiZUNxY21BTk1PSXhYbDgxcHNJK2lOVmpOUS84aHR6ZGJRbDI5?=
 =?utf-8?B?M2lvZHpibEYvMmFpZWtpRmpHRThMamlqTExXMVdaRDN2eStRZnRnL1dWcEoz?=
 =?utf-8?B?bW1hNXJEdHlySTNGazF4LzA1bzBPWEdWTG4vNWVlY2loSjZ1WWZ3MG1OVjE5?=
 =?utf-8?B?ZFdvVVM1eXJxOU5mQk5BOWRISW5UMENqdnRCckV6eFo2OXFsb09XQlc5Z0dF?=
 =?utf-8?B?d21OV3c0WHd0VDNDUnJvUW5CYTg2am4zVjJjTitNc3kxREcxaDZXMXJvcXZW?=
 =?utf-8?B?aDJyYjVvcjM1VkNPYnBYUHI1VFNqRU5QV3IvNGc3TUwzMGV4MjdRTDNmQk52?=
 =?utf-8?B?UzZHZi9xVXFMekFJNWlhOUI4L09odUJXc094THVDYnFpNjVkYllmajB1aVQ4?=
 =?utf-8?B?Vlo2ZlN5dVRCNEltMGtpWkRiemlWUEY2bnl2SEtPSU1KZm9PNW1JRFpBVW50?=
 =?utf-8?B?V0hWUXdpbnM0cjBROHFFN3E5TTJ0bDV0YzNwRlJMeWl4bmdSbUpvbVJQYVlQ?=
 =?utf-8?B?Tjh1RE5qaUR5SzlTT244V1l1RlRMU0wvRVF4RGhBeXFwOHExLzNwVGt0eWVP?=
 =?utf-8?B?THBiU1ppNy8wRThQZWdPTlArT3ZzdzBpTjBrZStiVmx4VVB2TFRzbEQ2cXhQ?=
 =?utf-8?B?WnJNODBIaGw3aFE1amJsRU1IVWZzOWsxYXdqeDBxVkNNQWdjNytUQUd2cFhw?=
 =?utf-8?B?bmJJUmIrZGUvZWV2aENzRTZSYnMraU5OTHpFWk45T2pDb3oyVDJhZEMrY2xR?=
 =?utf-8?B?eVoyaTVvU1UyK1o3dVRDYU5pbEUxVGI4Y1ZycmFmTHp2RDNDZ3hMYU5wVnQv?=
 =?utf-8?B?SXZ4UXBWMzdoNFNKb2tBRnRITWFuSGt2ZXk4eG5zTXMwUHM0RTVuQW9nSEoy?=
 =?utf-8?B?YXJmNEFqZVJibXF2ZGpJK09lSWFpamlRdmpjbjgybjdrRWxLc0lDK29qclBZ?=
 =?utf-8?B?TTZuSFhCS3RRYXNienk4MG5zLzBZWGlJV0Q1c09tYm5VbHphY2JVTnBzWlpa?=
 =?utf-8?B?OXpwU0pHM1N1ZEhuL0JycUk1K0ZpT3ZmTTZqOGV5UEhMWUoxLzhjVXdLbzNo?=
 =?utf-8?B?dGY0a21OT2NyWWtVaGdSSWZ0ZllYRkoxRkRhTlBZcEIybU50QXZ0a0N0M01w?=
 =?utf-8?B?aFBQS3gwajN6ek9LakRKMFZxLzdFb1J2cUNsU2Nsc2I5UjYvOURSWUtxM0w5?=
 =?utf-8?B?Qnl6SFd2akRxZUNjMEZiVFY3OFVGYmV3QXFVVGlybitJd2lNSGVEZ29CY2Rz?=
 =?utf-8?B?UVRDR3EyeXF6UFVNRWV6cG9QL2FBOGN4RWZjY1ZVZ1hWVy9oQ2VkazV5Y0Vs?=
 =?utf-8?B?R3FPYTM1Y1IrQXpmWFg1SWlLbStOZzB6RHY3TnN4YkZtdmRsTHphQjNOSHpz?=
 =?utf-8?B?ejZIQU5pa1hNUVN0cndHdGdwVmRmRndSNkdVWFFxUzhYTU1Bbm4xNGVvcHZQ?=
 =?utf-8?B?Z3dsdGUvRkFxa2lQT1VidTBSbldpYU1tbWdhVVFHYVJYOG9xcy9WT2FRYTR2?=
 =?utf-8?B?Q2dzSjNtVXJMMnV6czYxNmJmNmV6Ky9WRGFNK001YzhnL0FxV21XQVdYSXkv?=
 =?utf-8?B?Y0ZhSU5ZRWtxdTU4WHA0ZU1NRm9ic2NUVm9ZbUhRcnZ1bjAzM2RRU3Q0N3Zo?=
 =?utf-8?B?K3I5ems1WVgyVnZWUnI0UW9EUkxQVUZkWVE0L0dGdjQ5ZnRYdEwxSjdBMlQ2?=
 =?utf-8?Q?SijnVIzHPoq4G2o5elA3q+MBM?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0fb2da3a-0398-4aae-f120-08dc2d684774
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3108.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2024 14:21:47.9466
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: av7fZkuboLq0al5iZP0vtDSBjRvK3Rho9mxgqoenGgQg0c+DF55G5Lw/HTHH+/SzHtskh95vPdt+I3/rRD4f7A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6011

On 2/14/2024 4:06 AM, Borislav Petkov wrote:
> 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.
>

Will try :)
  
>> A similar solution is desirable for CPUs. However, this solution should
> 
> GPUs you mean?
>

I mean CPUs. GPUs would fall under the "add-in" card scenario.
  
>> 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.
>

Do you mean this should be left out of the commit message?
  
>> 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.
> 

Okay.

Thanks,
Yazen