From: Yazen Ghannam <yazen.ghannam@amd.com>
To: Borislav Petkov <bp@alien8.de>
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
Date: Wed, 14 Feb 2024 09:45:14 -0500 [thread overview]
Message-ID: <2a83026c-ea36-44ca-a101-74a8b3a2ea89@amd.com> (raw)
In-Reply-To: <20240214102926.GCZcyWBuEBe7WRXWYO@fat_crate.local>
On 2/14/2024 5:29 AM, Borislav Petkov wrote:
> On Tue, Feb 13, 2024 at 09:35:16PM -0600, Yazen Ghannam wrote:
>> +/* FRU Memory Poison Section, UEFI vX.Y sec N.X.Z */
>
> Whack those:
>
> diff --git a/drivers/ras/amd/fmpm.c b/drivers/ras/amd/fmpm.c
> index 328e0a962c23..0246b13b5ba1 100644
> --- a/drivers/ras/amd/fmpm.c
> +++ b/drivers/ras/amd/fmpm.c
> @@ -72,7 +72,7 @@
> /* FRU ID Types */
> #define FMP_ID_TYPE_X86_PPIN 0
>
> -/* FRU Memory Poison Section, UEFI vX.Y sec N.X.Z */
> +/* FRU Memory Poison Section */
> struct cper_sec_fru_mem_poison {
> u32 checksum;
> u64 validation_bits;
> @@ -89,7 +89,7 @@ struct cper_sec_fru_mem_poison {
> /* FRU Descriptor Address Types */
> #define FPD_ADDR_TYPE_MCA_ADDR 0
>
> -/* Memory Poison Descriptor, UEFI vX.Y sec N.X.Y */
> +/* Memory Poison Descriptor */
> struct cper_fru_poison_desc {
> u64 timestamp;
> u32 hw_id_type;
>
>
Ack.
>> +/**
>> + * DOC: fru_poison_entries (byte)
>> + * Maximum number of descriptor entries possible for each FRU.
>> + *
>> + * Values between '1' and '255' are valid.
>> + * No input or '0' will default to FMPM_DEFAULT_MAX_NR_ENTRIES.
>> + */
>> +static u8 max_nr_entries;
>> +module_param(max_nr_entries, byte, 0644);
>> +MODULE_PARM_DESC(max_nr_entries,
>> + "Maximum number of memory poison descriptor entries per FRU");
>
> Why is there a module parameter?
>
I didn't think too much on this one. I kept the idea from the old set.
Murali, Naveen, any comments?
> So that people can brick their BIOSes if it can't handle some size?
>
The ERST operations should fail and return an error status if there's not enough
space.
> Can we read out the max size of the area destined for FRU records from
> somewhere and go with it?
>
This idea was done in the old set. But it's not correct, IMO.
The 'size' we can see from ERST isn't necessarily the available storage size.
For the !NVRAM cases, it's the size of the temporary bounce buffer that BIOS
can use to pass records to and from the OS.
So it would be big enough to old the largest record BIOS expects. It doesn't
have to match the record size used in this module. ERST is used by other code
with different records.
>> +#define FMPM_DEFAULT_MAX_NR_ENTRIES 8
>> +
>> +/* Maximum number of FRUs in the system. */
>> +static unsigned int max_nr_fru;
>> +
>> +/* Total length of record including headers and list of descriptor entries. */
>> +static size_t max_rec_len;
>> +
>> +/*
>> + * Protect the local cache and prevent concurrent writes to storage.
>
> "local cache"?
>
Yes, we keep a local copy of the records within the module. That way we just need
to update the local copy and write it down to the platform. This saves time and
avoids interrupting the platform to do an extra read.
Thanks,
Yazen
next prev parent reply other threads:[~2024-02-14 14:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 3:35 [PATCH 0/2] " Yazen Ghannam
2024-02-14 3:35 ` [PATCH 1/2] RAS/AMD/ATL, EDAC/amd64: Move MI300 Row Retirement to ATL Yazen Ghannam
2024-02-14 8:36 ` Borislav Petkov
2024-02-14 14:19 ` Yazen Ghannam
2024-02-14 16:05 ` Borislav Petkov
2024-02-14 3:35 ` [PATCH 2/2] RAS: Introduce the FRU Memory Poison Manager Yazen Ghannam
2024-02-14 9:06 ` Borislav Petkov
2024-02-14 14:21 ` Yazen Ghannam
2024-02-14 15:49 ` Borislav Petkov
2024-02-14 16:01 ` Yazen Ghannam
2024-02-14 16:11 ` Borislav Petkov
2024-02-14 9:28 ` Borislav Petkov
2024-02-14 14:28 ` Yazen Ghannam
2024-02-14 17:50 ` Borislav Petkov
2024-02-14 18:21 ` Borislav Petkov
2024-02-14 10:29 ` Borislav Petkov
2024-02-14 14:45 ` Yazen Ghannam [this message]
2024-02-14 18:04 ` Borislav Petkov
2024-02-14 10:34 ` Borislav Petkov
2024-02-14 14:46 ` Yazen Ghannam
2024-02-14 18:29 ` Borislav Petkov
2024-02-14 10:51 ` Borislav Petkov
2024-02-14 14:49 ` Yazen Ghannam
2024-02-14 11:05 ` Borislav Petkov
2024-02-14 14:56 ` Yazen Ghannam
2024-02-14 18:44 ` Borislav Petkov
2024-02-14 11:10 ` Borislav Petkov
2024-02-14 14:57 ` Yazen Ghannam
2024-02-14 11:15 ` Borislav Petkov
2024-02-14 14:59 ` Yazen Ghannam
2024-02-14 11:36 ` Borislav Petkov
2024-02-14 15:26 ` Yazen Ghannam
2024-02-14 19:44 ` Borislav Petkov
2024-02-14 20:10 ` Borislav Petkov
2024-02-14 12:02 ` Borislav Petkov
2024-02-14 15:33 ` Yazen Ghannam
2024-02-14 20:18 ` Borislav Petkov
2024-02-14 18:47 ` Borislav Petkov
2024-02-14 7:52 ` [PATCH 0/2] " Borislav Petkov
2024-02-20 12:29 ` M K, Muralidhara
2024-02-20 17:10 ` M K, Muralidhara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2a83026c-ea36-44ca-a101-74a8b3a2ea89@amd.com \
--to=yazen.ghannam@amd.com \
--cc=avadhut.naik@amd.com \
--cc=bp@alien8.de \
--cc=john.allen@amd.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=muralidhara.mk@amd.com \
--cc=naveenkrishna.chatradhi@amd.com \
--cc=sathyapriya.k@amd.com \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®