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

[Mauro Carvalho Chehab <M.Chehab@huawei.com>]

On Mon, 22 Jun 2026 09:42:33 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> 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

Thank you to point it to me. I opted to open this as a bug:
	https://github.com/tianocore/edk2/issues/12708

As the root cause for such regression was another bug:
	https://github.com/tianocore/edk2/issues/10524
	

> 
> 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,
> > Maur  


-- 
Thanks,
Mauro