Page MenuHomePhabricator

End-of-interrupt (EOI) handling is missing for RAS interrupts
Closed, ResolvedPublic

Description

Resolved: I agree with comment by odeprez; the EOI belongs in the INDIVIDUAL RAS error handler since not all RAS errors involve the interrupt controller (as in a CPU exception).

Question: where does the EOI belong for a RAS interrupt? Does it belong In the [common] RAS priority handler or in the [individual] RAS error handler?
Currently, the RAS priority handler, 'ras_interrupt_handler()', does not perform EOI processing (i.e. it does not invoke 'plat_ic_end_of_interrupt()' after calling the [individual] RAS error handler).

I am encountering a problem when I dispatch an SDEI event from a RAS error handler. Although the SDEI event completes and returns to the RAS error handler, the system subsequently hangs.
If I invoke 'plat_ic_end_of_interrupt()' after the RAS error handler completes, the system operates normally.
I would expect that the platform EOI processing be invoked from the [common] RAS priority handler, rather than requiring it to be included in each and every RAS error handler.

Event Timeline

rickdic created this task.Dec 23 2019, 6:32 PM

Hi,

I'm not too much versed into RAS error handling, so please take my explanation below with care.
I suggest you send the question to the TF-A ML to get more sensible insights.

From what I understand, EOI should be done from the platform RAS handler (or "individual handler" as you mention) .

When looking at the platform sample plat/arm/css/sgi/sgi_ras.c,
plat_ic_end_of_interrupt is called from sgi_ras_intr_handler.

I suspect not all RAS errors require EOI, such as when the generated error is a CPU exception.
And so a reason EOI might not be done from common RAS handler.

Regards,
Olivier.

HI Rickdic,
Could you please send this query to the TF-A mailing list ?

rickdic closed this task as Resolved.Feb 15 2020, 10:01 PM
rickdic updated the task description. (Show Details)