Hi, On Wed, Jul 7, 2021 at 7:52 AM Sumit Garg <sumit.garg@xxxxxxxxxx> wrote: > > On Tue, 6 Jul 2021 at 18:16, Marc Zyngier <maz@xxxxxxxxxx> wrote: > > [snip] > > > > - Is there any case where you would instead need a level interrupt > > > > (which a SGI cannot provide)? > > > > > > I think SGI should be sufficient to suffice OP-TEE notifications use-case. > > > > I don't care about OP-TEE. If you are proposing a contract between S > > and NS, it has to be TEE and OS independent. That's how the > > architecture works. > > > > Agree, here we are not proposing a common contract among the S and NS > world that every TEE (based on Arm TrustZone) will use to communicate > with REE (Linux in our case) but rather an OP-TEE specific > notifications feature that is built on top of OP-TEE specific ABIs. > > And I can see your arguments coming from an FFA perspective but there > are platforms like the ones based on Armv7 which don't support FFA > ABI. Maybe Jens can elaborate how this feature will fit in when FFA > comes into picture? OP-TEE has one official ABI at the moment, the SMC based one. It's about to get another one based on FF-A instead. The two ABIs will never be used at the same time. It's a build time option for the OP-TEE firmware to either use SMC or FF-A based communication. The patches I've posted here concern the SMC based ABI. Asynchronous notification in OP-TEE with a FF-A based ABI will use the notification framework provided by FF-A instead to implement that counterpart provided by these patches. So the OP-TEE driver here in the kernel will use the FF-A framework in the kernel instead of registering an interrupt handler directly. Cheers, Jens
