Re: [RESEND] troubles with ARM processor type changes on UEFI 2.11

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 22 Jun 2026 10:25:18 +0200
Mauro Carvalho Chehab <mchehab@kernel.org> wrote:

> (as I got no answer, I'm resending it, c/c some ARM people as well)
> 
> Hi,
> 
> I maintain ACPI HEST support on QEMU and I'm one of the Linux kernel reviewers
> for the RAS subsystem. I'm also the author and maintainer of Linux rasdaemon,
> responsible to handle RAS reports (including from GHES) on Linux.
> 
> There is an incompatible change at UEFI 2.11 spec at Section N.2.4.4.1,
> which, according with UEFI 2.11 changelog, it is related to this issue:
> 
> 	2462 - Fix the Type mnemonic description in the ARM Processor Error Information Structure
> 
> This is the second time the specs changed the meaning of the type field
> inside the ARM processor error info:
> 
> - Before UEFI 2.9A, the spec has a list of values for error type. 
>   From the specs, type, at offset 4 was described as:
>     
>             - Cache error
>             - TLB Error
>             - Bus Error
>             - Micro-architectural Error
>             All other values are reserved
>     
>     Yet, there was no information about how this would be encoded.
>     
> - UEFI 2.9A defined the actual expected values as:
>     
>             - Bit 1 - Cache Error
>             - Bit 2 - TLB Error
>             - Bit 3 - Bus Error
>             - Bit 4 - Micro-architectural Error
>             All other values are reserved
> 
>     However, even being an incompatible change, the spec didn't change
>     version field at Section N.2.4.4.1.
> 
>    Linux, QEMU, rasdaemon and likely several BIOS implementations
>    were updated accordingly.
> 
> - UEFI 2.11 changed the definition to:
> 
>             - Bit 0 - Cache Error
>             - Bit 1 - TLB Error
>             - Bit 2 - Bus Error
>             - Bit 3 - Micro-architectural Error
>             All other values are reserved
> 
>   Again, another incompatible change and without changing the version
>   field at Section N.2.4.4.1.
> 
> With the current mess, it is impossible for the OSPM (and RAS apps) to
> properly map ARM processor error types, as for instance, type=2 can
> mean:
> 
> 	- Bus error (up to UEFI 2.9)
> 	- Cache error (UEFI 2.9A and UEFI 2.10)
> 	- TLB error (UEFI 2.11)
> 
> Please issue an errata incrementing version number, to allow OSPM
> QEMU and rasdaemon to properly interpret this field.
> 
FWIW I fully agree that an errata is needed. (Though, even though ambiguous,
changing meaning should probably have been done by deprecating that field
and adding a new one... too late now!) 

It seems a bit odd to do it this way but Mauro, you should be able
to file a code first proposal at:
https://github.com/tianocore/edk2/issues?q=is%3Aissue%20state%3Aopen%20label%3Atype%3Acode-first

Make sure it has a code first label.  I think you also need
someone to take it through the committee though (I'm sadly not
in a position to do so at the moment).

Samer or Jose (+CC), can you deal with this one?

Thanks,

Jonathan

> Thanks,
> Mauro