Hello,
I am using Pseudo-fault Generation Control Register(ERR0PFGCTL) of FEAT_RASv1p1 to inject SError exception for testing purposes on FVP platform.
I am able to inject an Uncorrected Error Type(UE) from EL1 and take the exception at EL2. But somehow for Corrected(CE) and Deferred(DE) errors, the SError exception does not trigger even though it seems to be correctly recorded in ERR0STATUS.CE/DE. any ideas why the exception is not taken for CE/DE errors?
What I really want is to inject a containable error that will be deferred at EL2 entry because of an ESB instruction so that I can read the differed error from DISR_EL1. Currently, whenever I inject a DE error + ESB, the DISR_EL1 reads zero.
Thanks in advance.
Thanks for the details, for now I am testing an SError exception handler, which is I guess unrelated to FHI(fault handling interrupt) or ERI(error recovery interrupt). I want to inject an uncorrected error that is containable/deferrable and contain that error by an ESB/IESB before the exception occurs and read the deferred SError via DISR_EL1. Is there a way to inject such error via the ERR0PFGCTL?
The RAS specification says:
" ISQCFG:
It is implementation-specific which physical errors are synchronized by Error synchronization events. However, the criteria for the PE error state mean that if the PE reports the PE error state as one of the following, the error must be either explicitly or implicitly synchronized by Error synchronization events:• Unrecoverable state (UEU).• Recoverable state (UER).• Restartable state (UEO).
This is because synchronized by Error synchronization events is a criterion for Unrecoverable state (UEU), and the criteria for Recoverable state (UER) and Restartable state (UEO) satisfy the definition of synchronized by Error synchronization events".
So theoretically, injecting those errors and enabling ESB/IESB, should synchronize those errors and be deferred to DISR_EL1.
Thanks.
As it says, this is "implementation specific" behavior. Whether this is supported depends heavily on the implementation. The CPU is very unlikely to support injection of an error state that it wouldn't reach on a real fault.