Possibility to loop in serror_aarch64 without making any progress

[vwadekar]

The RAS exception handler enables the ABT_BIT immediately upon entering the handler.

vector_entry serror_aarch64
msr daifclr, #DAIF_ABT_BIT
b enter_lower_el_async_ea
end_vector_entry serror_aarch64

For "clustered" SErrors, this means that we will constantly loop here without making any progress. Should we execute the ESB instruction before enabling the ABT_BIT to avoid this scenario?

[soby-mathew]

Yes, I think the esb would be needed for this, but it would have to be under RAS_EXTENSION build flag.

[vwadekar]

Also does it make sense to enable the ABT_BIT after the current SError has been handled? With this approach we can be very sure that the CPU gets a chance to make progress even on a broken system.

[soby-mathew]

Hi @vwadekar,
Your question got me thinking further on this and I realize that having an ESB with the PSTATE.A bit set causes the DISR_EL1 register to be updated for the synchronized errors rather than ESR_EL3.

The code snippet for handling SError from lower ELs assume that that all pending errors are synchronized when the exception is taken and the error reflects in ESR_EL3.

Now I am not sure whether once the pending errors are synchronized by ESB whether the Error Syndrome in the ESR_EL3 due to the first SError is still valid or not. This needs further reading up. I will try to get in touch with the Architecture team regarding this.

[soby-mathew]

Hi @vwadekar,
I got clarification that ESR_EL3 when the first SError was taken is still valid after further error synchronisation of errors via ESB. The syndrome in DISR_EL1 might say something else which can be combined with the one in ESR_EL3 and proceed on the worst case.

enable the ABT_BIT after the current SError has been handled?

Do you mean to set the ABT_BIT so as to keep the SError masked while executing in EL3 ? Errors attributed to EL3 are handled differently from the ones coming from lower EL. If the SErrors are masked, during EL3 execution, then this error attribution cannot happen anymore.

We assume that ESB will synchronize all errors attributed to lower EL on entry to EL3 and hence the above implementation.

[arm-tf-bot]

Hello @vwadekar!

Thank you for raising an issue for Trusted Firmware-A.

The TF-A project has now migrated to www.trustedfirmware.org. This issue tracker will still remain accessible for some time, but only for historical reasons. From now on you should raise any new issues on trustedfirmware.org.

How do I raise issues for TF-A?

Please use our new issue tracking board. For this you just need to login with your existing GitHub account. We also have a guide to help you raise the issue with the appropriate labels and tags. This way it will be easier for both you and us to track and address the issue most effectively.

What if I face any problems?

You can send us an email in the public TF-A mailing list. Here you can also find all the mailing lists for all the projects hosted under trustedfirmware.org.

We are looking forward to seeing you in trustedfirmware.org!

The Trusted Firmware-A team

[ssg-bot]

Hello @vwadekar!

Thank you for raising an issue for Trusted Firmware-A.

The TF-A project has now migrated to www.trustedfirmware.org. This issue tracker will still remain accessible for some time, but only for historical reasons. From now on you should raise any new issues on trustedfirmware.org.

How do I raise issues for TF-A?

Please use our new issue tracking board. For this you just need to login with your existing GitHub account. We also have a guide to help you raise the issue with the appropriate labels and tags. This way it will be easier for both you and us to track and address the issue most effectively.

What if I face any problems?

You can send us an email in the public TF-A mailing list. Here you can also find all the mailing lists for all the projects hosted under trustedfirmware.org.

We are looking forward to seeing you in trustedfirmware.org!

The Trusted Firmware-A team