linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Daniel Ferguson <danielf@os.amperecomputing.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>, "James Morse" <james.morse@arm.com>,
	Tony Luck <tony.luck@intel.com>, "Borislav Petkov" <bp@alien8.de>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-acpi@vger.kernel.org>, <linux-efi@vger.kernel.org>,
	<linux-edac@vger.kernel.org>,
	Jason Tian <jason@os.amperecomputing.com>,
	Shengwei Luo <luoshengwei@huawei.com>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Shiju Jose <shiju.jose@huawei.com>
Subject: Re: [PATCH v4 1/5] RAS: Report all ARM processor CPER information to userspace
Date: Fri, 8 Aug 2025 16:22:09 +0100	[thread overview]
Message-ID: <20250808162209.000068f5@huawei.com> (raw)
In-Reply-To: <20250805-mauro_v3-v6-16-rev2-v4-1-ea538759841c@os.amperecomputing.com>

On Tue, 05 Aug 2025 11:35:38 -0700
Daniel Ferguson <danielf@os.amperecomputing.com> wrote:

> From: Jason Tian <jason@os.amperecomputing.com>
> 
> The ARM processor CPER record was added in UEFI v2.6 and remained
> unchanged up to v2.10.
> 
> Yet, the original arm_event trace code added by
> 
>   e9279e83ad1f ("trace, ras: add ARM processor error trace event")
> 
> is incomplete, as it only traces some fields of UAPI 2.6 table N.16, not
> exporting any information from tables N.17 to N.29 of the record.
> 
> This is not enough for the user to be able to figure out what has
> exactly happened or to take appropriate action.
> 
> According to the UEFI v2.9 specification chapter N2.4.4, the ARM
> processor error section includes:
> 
> - several (ERR_INFO_NUM) ARM processor error information structures
>   (Tables N.17 to N.20);
> - several (CONTEXT_INFO_NUM) ARM processor context information
>   structures (Tables N.21 to N.29);
> - several vendor specific error information structures. The
>   size is given by Section Length minus the size of the other
>   fields.
> 
> In addition, it also exports two fields that are parsed by the GHES
> driver when firmware reports it, e.g.:
> 
> - error severity
> - CPU logical index
> 
> Report all of these information to userspace via a the ARM tracepoint so
> that userspace can properly record the error and take decisions related
> to CPU core isolation according to error severity and other info.
> 
> The updated ARM trace event now contains the following fields:
> 
> ======================================  =============================
> UEFI field on table N.16                ARM Processor trace fields
> ======================================  =============================
> Validation                              handled when filling data for
>                                         affinity MPIDR and running
>                                         state.
> ERR_INFO_NUM                            pei_len
> CONTEXT_INFO_NUM                        ctx_len
> Section Length                          indirectly reported by
>                                         pei_len, ctx_len and oem_len
> Error affinity level                    affinity
> MPIDR_EL1                               mpidr
> MIDR_EL1                                midr
> Running State                           running_state
> PSCI State                              psci_state
> Processor Error Information Structure   pei_err - count at pei_len
> Processor Context                       ctx_err- count at ctx_len
> Vendor Specific Error Info              oem - count at oem_len
> ======================================  =============================
> 
> It should be noted that decoding of tables N.17 to N.29, if needed, will
> be handled in userspace. That gives more flexibility, as there won't be
> any need to flood the kernel with micro-architecture specific error
> decoding.
> 
> Also, decoding the other fields require a complex logic, and should be
> done for each of the several values inside the record field.  So, let
> userspace daemons like rasdaemon decode them, parsing such tables and
> having vendor-specific micro-architecture-specific decoders.
> 
>   [mchehab: modified description, solved merge conflicts and fixed coding style]
> 
> Fixes: e9279e83ad1f ("trace, ras: add ARM processor error trace event")
> 

Fixes tag is part of the main tag block so no blank line here.
There are at least some scripts running on the kernel tree that trip
up on this (and one that moans at the submitter ;)

I'd also add something to explain the SoB sequence for the curious.

> Co-developed-by: Jason Tian <jason@os.amperecomputing.com>

Jason's the Author, so shouldn't have a Co-dev tag.
There is some info on this in
https://docs.kernel.org/process/submitting-patches.html

> Signed-off-by: Jason Tian <jason@os.amperecomputing.com>
> Co-developed-by: Shengwei Luo <luoshengwei@huawei.com>
> Signed-off-by: Shengwei Luo <luoshengwei@huawei.com>
> Co-developed-by: Daniel Ferguson <danielf@os.amperecomputing.com>
> Signed-off-by: Daniel Ferguson <danielf@os.amperecomputing.com>

As person submitting I'd normally expect your SoB last.

> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

I guess this is because Mauro posted an earlier version in which
case this is arguably correct, but likely to confuse.
For cases like this I add comments.

> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Tested-by: Shiju Jose <shiju.jose@huawei.com>
> Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
> Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-section

A couple of trivial things inline.

> diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
> index a6e4792a1b2e9239f44f29102a7cc058d64b93ef..179b1744df71ee1eac28718628d550075c480cd5 100644
> --- a/drivers/ras/ras.c
> +++ b/drivers/ras/ras.c
> @@ -52,9 +52,46 @@ void log_non_standard_event(const guid_t *sec_type, const guid_t *fru_id,
>  	trace_non_standard_event(sec_type, fru_id, fru_text, sev, err, len);
>  }
>  
> -void log_arm_hw_error(struct cper_sec_proc_arm *err)
> +void log_arm_hw_error(struct cper_sec_proc_arm *err, const u8 sev)
>  {
> -	trace_arm_event(err);
> +	struct cper_arm_err_info *err_info;
> +	struct cper_arm_ctx_info *ctx_info;
> +	u8 *ven_err_data;
> +	u32 ctx_len = 0;
> +	int n, sz, cpu;
> +	s32 vsei_len;
> +	u32 pei_len;
> +	u8 *pei_err;
> +	u8 *ctx_err;

Maybe combine the two u8 *

> +
> +	pei_len = sizeof(struct cper_arm_err_info) * err->err_info_num;
> +	pei_err = (u8 *)err + sizeof(struct cper_sec_proc_arm);
	pei_err = (u8 *)(err + 1);

Which is the same as err_info. Setting one to the other will make that
relationship more obvious if we do need to keep them both around.
(Similar to the ctx_err = (u8 *)ctx_info; below)

> +
> +	err_info = (struct cper_arm_err_info *)(err + 1);
> +	ctx_info = (struct cper_arm_ctx_info *)(err_info + err->err_info_num);
> +	ctx_err = (u8 *)ctx_info;
> +
> +	for (n = 0; n < err->context_info_num; n++) {
> +		sz = sizeof(struct cper_arm_ctx_info) + ctx_info->size;
> +		ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + sz);
> +		ctx_len += sz;
> +	}
> +
> +	vsei_len = err->section_length - (sizeof(struct cper_sec_proc_arm) + pei_len + ctx_len);
> +	if (vsei_len < 0) {
> +		pr_warn(FW_BUG "section length: %d\n", err->section_length);
> +		pr_warn(FW_BUG "section length is too small\n");
> +		pr_warn(FW_BUG "firmware-generated error record is incorrect\n");
> +		vsei_len = 0;
> +	}
> +	ven_err_data = (u8 *)ctx_info;
> +
> +	cpu = GET_LOGICAL_INDEX(err->mpidr);
> +	if (cpu < 0)
> +		cpu = -1;
> +
> +	trace_arm_event(err, pei_err, pei_len, ctx_err, ctx_len,
> +			ven_err_data, (u32)vsei_len, sev, cpu);
>  }

> diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
> index 14c9f943d53fb6cbadeef3f4b13e61470f0b5dee..a6b7ac0adaff9dfeab05a0c75ed359930ae04479 100644
> --- a/include/ras/ras_event.h
> +++ b/include/ras/ras_event.h
> @@ -168,11 +168,24 @@ TRACE_EVENT(mc_event,
>   * This event is generated when hardware detects an ARM processor error
>   * has occurred. UEFI 2.6 spec section N.2.4.4.
>   */
> +#define APEIL "ARM Processor Err Info data len"
> +#define APEID "ARM Processor Err Info raw data"
> +#define APECIL "ARM Processor Err Context Info data len"
> +#define APECID "ARM Processor Err Context Info raw data"
> +#define VSEIL "Vendor Specific Err Info data len"
> +#define VSEID "Vendor Specific Err Info raw data"
>  TRACE_EVENT(arm_event,
>  
> -	TP_PROTO(const struct cper_sec_proc_arm *proc),
> +	TP_PROTO(const struct cper_sec_proc_arm *proc, const u8 *pei_err,
> +			const u32 pei_len,
Trivial but this is an odd bit of wrapping to have two items
on first line, but then only one on later lines.  Also additional
indent seems unusual and isn't matched by the first few things I looked
at in this file.  So should be under the c of const (one space I think
rather than a tab).

> +			const u8 *ctx_err,
> +			const u32 ctx_len,
> +			const u8 *oem,
> +			const u32 oem_len,
> +			u8 sev,
> +			int cpu),
>  




  reply	other threads:[~2025-08-08 15:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-05 18:35 [PATCH v4 0/5] Fix issues with ARM Processor CPER records Daniel Ferguson
2025-08-05 18:35 ` [PATCH v4 1/5] RAS: Report all ARM processor CPER information to userspace Daniel Ferguson
2025-08-08 15:22   ` Jonathan Cameron [this message]
2025-08-09 15:55     ` Mauro Carvalho Chehab
2025-08-11 10:52       ` Jonathan Cameron
2025-08-11 22:37         ` Daniel Ferguson
2025-08-12 14:05           ` Jonathan Cameron
2025-08-05 18:35 ` [PATCH v4 2/5] efi/cper: Adjust infopfx size to accept an extra space Daniel Ferguson
2025-08-05 18:35 ` [PATCH v4 3/5] efi/cper: Add a new helper function to print bitmasks Daniel Ferguson
2025-08-08 15:23   ` Jonathan Cameron
2025-08-05 18:35 ` [PATCH v4 4/5] efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs Daniel Ferguson
2025-08-05 18:35 ` [PATCH v4 5/5] docs: efi: add CPER functions to driver-api Daniel Ferguson
2025-08-05 18:39 ` [PATCH v4 0/5] Fix issues with ARM Processor CPER records Daniel Ferguson
2025-08-08 15:01   ` Jonathan Cameron
2025-08-08 19:03     ` Daniel Ferguson
2025-08-09 15:49       ` Mauro Carvalho Chehab

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=20250808162209.000068f5@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=danielf@os.amperecomputing.com \
    --cc=james.morse@arm.com \
    --cc=jason@os.amperecomputing.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luoshengwei@huawei.com \
    --cc=mchehab+huawei@kernel.org \
    --cc=rafael@kernel.org \
    --cc=shiju.jose@huawei.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;
as well as URLs for NNTP newsgroup(s).