[RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases

[Hiremath, Vaibhav]

> -----Original Message-----
> From: bhupesh.sharma at freescale.com
> [mailto:bhupesh.sharma at freescale.com]
> Sent: Monday, January 06, 2014 11:02 AM
> To: Hiremath, Vaibhav; 'linux-arm-kernel at lists.infradead.org'
> Cc: 'Tony Lindgren'; 'linux-omap at vger.kernel.org'; 'Russell King'
> Subject: RE: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure
> communication use-cases
> 
> > -----Original Message-----
> > From: linux-arm-kernel [mailto:linux-arm-kernel-
> > bounces at lists.infradead.org] On Behalf Of Hiremath, Vaibhav
> > Sent: Monday, January 06, 2014 10:39 AM
> > To: linux-arm-kernel at lists.infradead.org
> > Cc: Tony Lindgren; linux-omap at vger.kernel.org; Russell King
> > Subject: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure
> > communication use-cases
> >
> > Hi,
> >
> > Currently the Software Generated Interrupts (SGI) are restricted to
> > use only for SMP architecture for inter-processor communication as
> > rightly documented in ARM GIC spec V1.
> >
> > In the system with the uniprocessor (and/or multiprocessor variants)
> > architecture with TRUSTZONE enabled device (like, AM43xx device), the
> > SGI can be used for communication between secure-to-nonsecure world.
> > And in order to enable SGI event from secure world to non-secure
> > world, GIC driver __must__ support registration of interrupt service
> > routines for SGI's; which is currently restricted by GIC driver.
> 
> I am not an expert on this, but as per my understanding the model
> recommended by ARM is the use of IRQ as a Normal world interrupt source, and
> FIQ as the Secure world source.
> 
[Hiremath, Vaibhav] Absolutely and I also follow same recommendation here.

> If IRQ is received by the Secure world, it should cause a hardware trap to the
> monitor and the monitor mode should cause a context switch and jumps to the
> normal world, where the interrupt handler should execute (see reference [1]).
> 

I think I missed to explicitly talk about FIQ in the RFC, sorry for the confusion.
Yes, IRQ received by secure world should cause HW trap to monitor mode and 
Further should cause context switch to public world to handle the interrupt.

And this RFC wants to leverage this, where, any operations on secure world,

        - Functional operation (entered through monitor mode) which want to pass on the 
          event to public world
        - Any FIQ (secure interrupts) wants to pass on certain events or information to
           Public world - It could be any secure peripheral interrupt causing FIQ

Secure world can use IRQ, which is generated by software to pass on the event information
to public world. Please note that, the SGI is non-secure, so if you raise and SGI from secure 
world it will follow the execution mentioned above.

So this RFC enables asynchronous communication channel between secure world to 
Non-secure world using SGI.

> For making a transition from the secure world to the normal world and vice-
> versa, the core should transition via the monitor mode. Assuming a
> Uniprocessor system running both Normal and Secure world - thus providing a
> view of two virtual processors running in a time-sliced fashion, the world in
> which the processor is executing should be indicated by the NS-bit in the Secure
> Configuration Register (SCR) in CP15. The IRQ, FIQ, Abort exceptions can all be
> configured to cause the processor to switch into monitor mode.
> 
> The software that executes within monitor mode is implementation defined, but
> it generally saves the state of the current world and restores the state of the
> world being switched to.
> It then performs a return-from-exception to restart processing in the restored
> world. (see reference [2]).
> 
> Does this RFC implementation take into account the monitor mode switch while
> switching/passing information b/w the two worlds?
> 

Yes, as recommended by ARM, this RFC is also based on the recommendation, where,
monitor mode is responsible for saving and restoring contexts.
RFC doesn't handle the monitor mode implementation which lacks context save/restore.

Please let me know if you still have any confusion on the usecase and on this RFC

Thanks,
Vaibhav