On Thu, Jul 28, 2016 at 08:43:46AM +0800, Heyi Guo wrote:
Hi folks,
We can see that in a single timer interrupt, there will be two writes to EOIR, one in timer interrupt handler, the other in GIC IRQ handler.
Without looking at the code: that sounds like a bug.
The question is: does two writes to EOIR have any side effect? From GIC specification (ARM IHI 0069B (ID121715)), we can see below text about writing EOIR (page 205):
A write to this register must correspond to the most recent valid read from an Interrupt Acknowledge Register for which there has not been a priority drop and that this identifier was read from ICC_IAR1_EL1 while operating in the same Security state as that in which the write occurs, otherwise the system behavior is UNPREDICTABLE. A valid read is a read that returns a valid interrupt ID, that is not a special INTID.
For GICv2, we can also see below text about EOIR:
For nested interrupts, the order of writes to this register must be the reverse of the order of interrupt acknowledgement. Behavior is UNPREDICTABLE if: • This ordering constraint is not maintained. *• The value written to this register does not match an active interrupt, or the ID of a spurious interrupt. * • The value written to this register does not match the last valid interrupt value read from GICC_IAR.
When we issue the 1st EOIR, the interrupt will be deactivated, so it is not in active state anymore for the 2nd write of EOIR.
Could anyone help to confirm whether it is OK to keep the 2nd write of EOIR? And how to explain the above paragraphs from GIC specification?
I don't think keeping the 2nd write to EOIR is OK. In the best possible scenario, there remains a race condition in which this could cause interrupts to be dropped.
Regards,
Leif