summaryrefslogtreecommitdiff
path: root/services
diff options
context:
space:
mode:
authorJeenu Viswambharan <jeenu.viswambharan@arm.com>2017-10-04 12:21:34 +0100
committerJeenu Viswambharan <jeenu.viswambharan@arm.com>2017-11-13 07:49:30 +0000
commit3d732e23e71343f2ba18d456c8f2163015209768 (patch)
tree8cfd70e85966e42b56b8b90a5631a2b55f038bbd /services
parent21b818c05fa4ec8cec468aad690267c5be930ccd (diff)
BL31: Program Priority Mask for SMC handling
On GICv3 systems, as a side effect of adding provision to handle EL3 interrupts (unconditionally routing FIQs to EL3), pending Non-secure interrupts (signalled as FIQs) may preempt execution in lower Secure ELs [1]. This will inadvertently disrupt the semantics of Fast SMC (previously called Atomic SMC) calls. To retain semantics of Fast SMCs, the GIC PMR must be programmed to prevent Non-secure interrupts from preempting Secure execution. To that effect, two new functions in the Exception Handling Framework subscribe to events introduced in an earlier commit: - Upon 'cm_exited_normal_world', the Non-secure PMR is stashed, and the PMR is programmed to the highest Non-secure interrupt priority. - Upon 'cm_entering_normal_world', the previously stashed Non-secure PMR is restored. The above sequence however prevents Yielding SMCs from being preempted by Non-secure interrupts as intended. To facilitate this, the public API exc_allow_ns_preemption() is introduced that programs the PMR to the original Non-secure PMR value. Another API exc_is_ns_preemption_allowed() is also introduced to check if exc_allow_ns_preemption() had been called previously. API documentation to follow. [1] On GICv2 systems, this isn't a problem as, unlike GICv3, pending NS IRQs during Secure execution are signalled as IRQs, which aren't routed to EL3. Change-Id: Ief96b162b0067179b1012332cd991ee1b3051dd0 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
Diffstat (limited to 'services')
0 files changed, 0 insertions, 0 deletions