make RAS interrupt handling optional

[DavidPu]

With current RAS framework, both RAS interrupt and external abort need to be implemented at platform level. It's better to make RAS interrupt optional so platform has choice to handle EA only at EL3 without introducing the EHF framework.

[soby-mathew]

@DavidPu , we will get back to you on this query in a week's time. Apologies for the delay on this.

[ghost]

@DavidPu, can you provide a bit more information as to why using the EHF framework is problematic in your case? Instead of bypassing the EHF framework, if there is something that prevents you from handling only EA at EL3 without having to assign an explicit priority it is better to fix that instead. That way, the handling is more consistent and any future changes that go into EHF will take into account your use-case as well.

[DavidPu]

Hi @dp-arm , In our current use case, RAS correctable error (FHI) is routed to lower EL so only EA handler is required to hookup in platform code.

But in current RAS framework, EL3_EXCEPTION_HANDLING shall be 1 if RAS_EXTENTION is enabled. And as long as we enable EL3_EXCEPTION_HANDLING , we need to hook EHF related platform interrupt mappings(which is dummy for our use case) or it won't compile. It looks to me instead of keeping EHF related dummy data, we'd better simply make EL3_EXCEPTION_HANDLING(which is used for RAS FHI only in this case) optional even RAS_EXTENTION=1.

[soby-mathew]

Hi @DavidPu, The Exception Handling Framework (EHF) attempts to assign the notion of priority to External Aborts (SError) and manage various asynchronous events in the system. In the case of Interrupts, this is taken care of in hardware via the Interrupt controller (GIC). EHF tries to couple this priority handling of interrupts with External Aborts being triggered thus enabling software to detect priority inversions and partition asynchronous event handling into different priority blocks.

The general rule is that the External Aborts must have the highest priority in the system. If the External Abort is used to deliver RAS Error, then PLAT_RAS_PRI must be the defined to be highest priority in the system. If some interrupts are also used to deliver the RAS error, then the same priority is also set for them in the GIC and lower priority interrupts are masked. This is why the RAS framework in TF-A has data structures to define SError and Interrupts.

See here for more details : https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/exception-handling.rst#2the-role-of-exception-handling-framework

In your case, since you are only concerned with External Aborts for delivering RAS Errors, I couldn't find any other easy solution other than defining a dummy ras_interrupt_mappings.

Hope that clarifies.

[arm-tf-bot]

Hello DavidPu!

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?

We have many channels through which you can contact us:

• Our mailing lists
  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.

• Our public IRC channel
  You can use the #trusted-firmware-a channel on the Freenode IRC network to quickly and easily reach us!

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

The Trusted Firmware-A team

[soby-mathew]

@DavidPu, we can continue discussion on the TF-A mailing list if required. Closing this issue.