From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V5 03/10] efi: parse ARMv8 processor error
Date: Fri, 25 Nov 2016 18:23:15 +0000 [thread overview]
Message-ID: <58388193.6000202@arm.com> (raw)
In-Reply-To: <1479767763-27532-4-git-send-email-tbaicar@codeaurora.org>
Hi Tyler,
On 21/11/16 22:35, Tyler Baicar wrote:
> Add support for ARMv8 Common Platform Error Record (CPER).
> UEFI 2.6 specification adds support for ARMv8 specific
> processor error information to be reported as part of the
> CPER records. This provides more detail on for processor error logs.
I think I'm missing a big part of the puzzle here, I will come back to this next
week. I can't quite line up some of the masks and shifts with the table
descriptions in the UEFI spec[0].
> diff --git a/include/linux/cper.h b/include/linux/cper.h
> index 13ea41c..2a9d553 100644
> --- a/include/linux/cper.h
> +++ b/include/linux/cper.h
> @@ -180,6 +185,10 @@ enum {
> #define CPER_SEC_PROC_IPF \
> UUID_LE(0xE429FAF1, 0x3CB7, 0x11D4, 0x0B, 0xCA, 0x07, 0x00, \
> 0x80, 0xC7, 0x3C, 0x88, 0x81)
> +/* Processor Specific: ARMv8 */
> +#define CPER_SEC_PROC_ARMV8 \
> + UUID_LE(0xE19E3D16, 0xBC11, 0x11E4, 0x9C, 0xAA, 0xC2, 0x05, \
> + 0x1D, 0x5D, 0x46, 0xB0)
Nit: UEFI v2.6 N.2.2 (table 249) describes this as 'ARM' not 'ARMV8' (which is
an architectural version).
> /* Platform Memory */
> #define CPER_SEC_PLATFORM_MEM \
> UUID_LE(0xA5BC1114, 0x6F64, 0x4EDE, 0xB8, 0x63, 0x3E, 0x83, \
> @@ -255,6 +264,34 @@ enum {
>
> #define CPER_PCIE_SLOT_SHIFT 3
>
> +#define CPER_ARMV8_ERR_INFO_NUM_MASK 0x00000000000000FF
> +#define CPER_ARMV8_CTX_INFO_NUM_MASK 0x0000000000FFFF00
Table 260 describes both ERR_INFO_NUM and CONTEXT_INFO_NUM for as both being
2bytes long, as does your struct cper_sec_proc_armv8 below. Are these for
something else? Do these correspond with one of the four bitfield formats
described in Table 262->265?
I can't see where they are used, and they look like they are reaching across
multiple fields in a struct.
> +#define CPER_ARMV8_CTX_INFO_NUM_SHIFT 8
> +
> +#define CPER_ARMV8_VALID_MPIDR 0x00000001
> +#define CPER_ARMV8_VALID_AFFINITY_LEVEL 0x00000002
> +#define CPER_ARMV8_VALID_RUNNING_STATE 0x00000004
> +#define CPER_ARMV8_VALID_VENDOR_INFO 0x00000008
> +
> +#define CPER_ARMV8_INFO_VALID_MULTI_ERR 0x0001
> +#define CPER_ARMV8_INFO_VALID_FLAGS 0x0002
> +#define CPER_ARMV8_INFO_VALID_ERR_INFO 0x0004
> +#define CPER_ARMV8_INFO_VALID_VIRT_ADDR 0x0008
> +#define CPER_ARMV8_INFO_VALID_PHYSICAL_ADDR 0x0010
> +
> +#define CPER_ARMV8_INFO_FLAGS_FIRST 0x0001
> +#define CPER_ARMV8_INFO_FLAGS_LAST 0x0002
> +#define CPER_ARMV8_INFO_FLAGS_PROPAGATED 0x0004
> +
> +#define CPER_AARCH64_CTX_LEN 368
> +#define CPER_AARCH32_CTX_LEN 256
Are these the worst case sizes for combinations of the structures in N2.4.4.2?
(Tables 266 to 273)
If so is there any chance they could be sizeof(<some union of structs>), even if
the structs are things like:
> /* ARMv8 AArch64 GPRs (Type 4) - defined in UEFI Spec N2.4.4.2 */
> struct cper_armv8_aarch64_gprs {
> u64 regs[32];
> }
This way its easier to check the number is correct, and if a new type is added
this won't get forgotten.
> +#define CPER_ARMV8_CTX_TYPE_MASK 0x000000000000000F
> +#define CPER_ARMV8_CTX_EL_MASK 0x0000000000000070
> +#define CPER_ARMV8_CTX_NS_MASK 0x0000000000000080
> +#define CPER_ARMV8_CTX_EL_SHIFT 4
> +#define CPER_ARMV8_CTX_NS_SHIFT 7
> +
Again, I can't work out what these correspond to. I can't see a secure bit or EL
field in any of those UEFI tables.
Is this one of the 'ARM Vendor Specific Micro-Architecture Error Structure's? If
so we should have some infrastructure for picking the correct (or unknown)
decode function based on a range of MIDRs.
> #define acpi_hest_generic_data_error_length(gdata) \
> (((struct acpi_hest_generic_data *)(gdata))->error_data_length)
> #define acpi_hest_generic_data_size(gdata) \
> @@ -352,6 +389,41 @@ struct cper_ia_proc_ctx {
> __u64 mm_reg_addr;
> };
>
> +/* ARMv8 Processor Error Section */
> +struct cper_sec_proc_armv8 {
> + __u32 validation_bits;
> + __u16 err_info_num; /* Number of Processor Error Info */
> + __u16 context_info_num; /* Number of Processor Context Info Records*/
> + __u32 section_length;
> + __u8 affinity_level;
> + __u8 reserved[3]; /* must be zero */
> + __u64 mpidr;
> + __u64 midr;
> + __u32 running_state; /* Bit 0 set - Processor running. PSCI = 0 */
> + __u32 psci_state;
> +};
> +
> +/* ARMv8 Processor Error Information Structure */
> +struct cper_armv8_err_info {
> + __u8 version;
> + __u8 length;
> + __u16 validation_bits;
> + __u8 type;
> + __u16 multiple_error;
> + __u8 flags;
> + __u64 error_info;
> + __u64 virt_fault_addr;
> + __u64 physical_fault_addr;
> +};
> +/* ARMv8 AARCH64 Processor Context Information Structure */
> +struct cper_armv8_aarch64_ctx {
> + __u8 type_el_ns;
> + __u8 reserved[7]; /* must be zero */
> + __u8 gpr[288];
> + __u8 spr[68];
> +};
Is this:
"Table 265. ARM Processor Error Context Information Header Structure"?
Sorry if I've missed something blindingly obvious!
Thanks,
James
[0] http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf
next prev parent reply other threads:[~2016-11-25 18:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-21 22:35 [PATCH V5 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64 Tyler Baicar
2016-11-21 22:35 ` [PATCH V5 01/10] acpi: apei: read ack upon ghes record consumption Tyler Baicar
2016-11-25 18:19 ` James Morse
2016-11-21 22:35 ` [PATCH V5 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1 Tyler Baicar
2016-11-25 18:20 ` James Morse
2016-11-28 18:55 ` Baicar, Tyler
2016-11-29 11:29 ` Shiju Jose
2016-11-29 17:30 ` Baicar, Tyler
2016-11-29 12:26 ` Shiju Jose
2016-11-21 22:35 ` [PATCH V5 03/10] efi: parse ARMv8 processor error Tyler Baicar
2016-11-25 18:23 ` James Morse [this message]
2016-11-29 15:37 ` Baicar, Tyler
2016-11-21 22:35 ` [PATCH V5 04/10] arm64: exception: handle Synchronous External Abort Tyler Baicar
2016-11-21 22:35 ` [PATCH V5 05/10] acpi: apei: handle SEA notification type for ARMv8 Tyler Baicar
2016-11-21 22:35 ` [PATCH V5 06/10] acpi: apei: panic OS with fatal error status block Tyler Baicar
2016-11-21 22:36 ` [PATCH V5 07/10] efi: print unrecognized CPER section Tyler Baicar
2016-11-21 22:36 ` [PATCH V5 08/10] ras: acpi / apei: generate trace event for " Tyler Baicar
2016-11-21 22:36 ` [PATCH V5 09/10] trace, ras: add ARM processor error trace event Tyler Baicar
2016-11-21 22:36 ` [PATCH V5 10/10] arm/arm64: KVM: add guest SEA support Tyler Baicar
2016-11-22 11:11 ` [PATCH V5 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64 John Garry
2016-11-22 17:13 ` Baicar, Tyler
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=58388193.6000202@arm.com \
--to=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).