Re: [TF-A] GICV3: system interface EOI ordering RFC

Hi Olivier,

-----Original Message----- From: Olivier Deprez [mailto:Olivier.Deprez@arm.com] Sent: Monday, June 08, 2020 1:14 PM To: tf-a@lists.trustedfirmware.org; Sandeep Tripathy Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC

Hi Sandeep,

gicv3_end_of_interrupt_sel1 is a static access helper macro. Its naming precisely tells what it does at gicv3 module level. It is called from

the weak

plat_ic_end_of_interrupt function for BL32 image.

I tend to think it is the driver responsibility to ensure the module

interrupt

acknowledge register write is reaching HW in order (or "be visible to

all

observers").

The driver should be agnostic of what interrupt controller is used and its behavior. And since 'all' writes were to mmio ranges mapped Device(nGnRE) /strongly-ordered(nGnRnE) there was no such need. This is a special case for GICv3 system interface only. Adding at driver level a DSB is unnecessary for other interrupt controllers.

Also I suspect adding a dsb might not be required generically for all

kind of IP.

Here are you referring to the peripheral IP or interrupt controller IP ? The issue is reordering at arm core itself (STR to device address Vs msr(sysreg write)). So I think Its applicable for all IP.

Adding a barrier in generic code might incur an unnecessary bottleneck.

But if there is a need to *ensure* presence of at least one DSB between the write transfer from core to device clear and gicv3 eoi icc register write in a generic way then what other option we have.

Thus wouldn't it be better to add the barrier to the overridden platform function rather than in generic gicv3 code?

That can be done but I feel this is more to do with gicv3 system interface only. Inside plat_xxx one has to check #if GICV3 ...and system interface.

I have a put a comment in the review, we can continue the discussion

there.

Regards, Olivier.

Thanks Sandeep

---

From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of Sandeep Tripathy via TF-A tf-a@lists.trustedfirmware.org Sent: 05 June 2020 19:43 To: tf-a@lists.trustedfirmware.org Subject: [TF-A] GICV3: system interface EOI ordering RFC

Hi, In a typical interrupt handling sequence we do 1-Read IAR 2-Do interrupt handling 3-Clear the interrupt at source , so that the device de-asserts IRQ

request to

GIC >> I am suggesting a need of DSB here in case of GICv3 +. 4-Write to GIC cpu interface to do EOI.

Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write over

AMBA

interface. The Addresses are mapped with (nR) attribute. Hence the write transfers

from the

core will be generated at step 3 and 4 in order. Please ignore the additional

buffers/bridges

in path from core till peripheral which has to be dealt separately as per SOC.

Query: I understand GICv3 system interface accesses are not over this

protocol

and core will not follow the ordering rule ?

I have observed spurious interrupt issue/manifestation ( I don't have

the

transfers probed) in RTOS environment where I have a primitive GICv3 driver but I wonder why things does not fail in Linux or tf-a. If it is working because from step(3) to

step(4) we have

barriers by chace due to other device register writes then I would suggest to have one in

the EOI

clearing API itself.

RFC:

https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454

Thanks Sandeep