summaryrefslogtreecommitdiff
path: root/bl31/ehf.c
AgeCommit message (Collapse)Author
2018-02-27EHF: Introduce preempted return code parameter to ehf_allow_ns_preemption()Jeenu Viswambharan
When a Yielding SMC is preempted, it's possible that Non-secure world is resumed afterwards. In this case, Non-secure execution would find itself in a state where the SMC has returned. However, the dispatcher might not get an opportunity to populate the corrected return code for having been preempted, and therefore the caller of the Yielding SMC cannot reliably determine whether the SMC had successfully completed or had been preempted. To solve this, this patch introduces a new parameter to the ehf_allow_ns_preemption() API. An SPD, through this parameter, would provide the expected error code when a Yielding SMC is preempted. EHF can then populate the specified value in x0 of the Non-secure context so that the caller of the Yielding SMC correctly identifies the SMC return as a preemption. Documentation updates to follow. Change-Id: Ia9c3f8f03f9d72d81aa235eaae2ee0374b972e1e Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-02-12EHF: Fix priority checkJeenu Viswambharan
When deactivating, it's not an error if the priority being deactivating is equal to the active priority. Fix this. Change-Id: I66f0e9e775ac9aba8a7cc48cd3ecd3b358be63c0 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-11-13BL31: Program Priority Mask for SMC handlingJeenu Viswambharan
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>
2017-11-13BL31: Introduce Exception Handling FrameworkJeenu Viswambharan
EHF is a framework that allows dispatching of EL3 interrupts to their respective handlers in EL3. This framework facilitates the firmware-first error handling policy in which asynchronous exceptions may be routed to EL3. Such exceptions may be handed over to respective exception handlers. Individual handlers might further delegate exception handling to lower ELs. The framework associates the delegated execution to lower ELs with a priority value. For interrupts, this corresponds to the priorities programmed in GIC; for other types of exceptions, viz. SErrors or Synchronous External Aborts, individual dispatchers shall explicitly associate delegation to a secure priority. In order to prevent lower priority interrupts from preempting higher priority execution, the framework provides helpers to control preemption by virtue of programming Priority Mask register in the interrupt controller. This commit allows for handling interrupts targeted at EL3. Exception handlers own interrupts by assigning them a range of secure priorities, and registering handlers for each priority range it owns. Support for exception handling in BL31 image is enabled by setting the build option EL3_EXCEPTION_HANDLING=1. Documentation to follow. NOTE: The framework assumes the priority scheme supported by platform interrupt controller is compliant with that of ARM GIC architecture (v2 or later). Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>