Skip to content

GitLab

Switch branch/tag
  1. 29 Nov, 2017 1 commit
  3. 21 Nov, 2017 1 commit
  5. 20 Nov, 2017 2 commits
  7. 17 Nov, 2017 1 commit
  9. 15 Nov, 2017 1 commit
    • David Cunado's avatar
      Move FPEXC32_EL2 to FP Context · 91089f36
      David Cunado authored 
      

The FPEXC32_EL2 register controls SIMD and FP functionality when the
lower ELs are executing in AArch32 mode. It is architecturally mapped
to AArch32 system register FPEXC.

This patch removes FPEXC32_EL2 register from the System Register context
and adds it to the floating-point context. EL3 only saves / restores the
floating-point context if the build option CTX_INCLUDE_FPREGS is set to 1.

The rationale for this change is that if the Secure world is using FP
functionality and EL3 is not managing the FP context, then the Secure
world will save / restore the appropriate FP registers.

NOTE - this is a break in behaviour in the unlikely case that
CTX_INCLUDE_FPREGS is set to 0 and the platform contains an AArch32
Secure Payload that modifies FPEXC, but does not save and restore
this register

Change-Id: Iab80abcbfe302752d52b323b4abcc334b585c184
Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      91089f36
  11. 13 Nov, 2017 9 commits
    • Jeenu Viswambharan's avatar
      SDEI: Add API for explicit dispatch · 55a1266e
      Jeenu Viswambharan authored 
      

This allows for other EL3 components to schedule an SDEI event dispatch
to Normal world upon the next ERET. The API usage constrains are set out
in the SDEI dispatcher documentation.

Documentation to follow.

Change-Id: Id534bae0fd85afc94523490098c81f85c4e8f019
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      55a1266e
    • Jeenu Viswambharan's avatar
      ARM platforms: Enable SDEI · 0baec2ab
      Jeenu Viswambharan authored 
      

Support SDEI on ARM platforms using frameworks implemented in earlier
patches by defining and exporting SDEI events: this patch defines the
standard event 0, and a handful of shared and private dynamic events.

Change-Id: I9d3d92a92cff646b8cc55eabda78e140deaa24e1
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      0baec2ab
    • Jeenu Viswambharan's avatar
      ARM platforms: Define exception macros · 0bef0edf
      Jeenu Viswambharan authored 
      

Define number of priority bits, and allocate priority levels for SDEI.

Change-Id: Ib6bb6c5c09397f7caef950c4caed5a737b3d4112
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      0bef0edf
    • Jeenu Viswambharan's avatar
      ARM platforms: Provide SDEI entry point validation · 781f4aac
      Jeenu Viswambharan authored 
      

Provide a strong definition for plat_sdei_validate_sdei_entrypoint()
which translates client address to Physical Address, and then validating
the address to be present in DRAM.

Change-Id: Ib93eb66b413d638aa5524d1b3de36aa16d38ea11
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      781f4aac
    • Jeenu Viswambharan's avatar
      ARM platforms: Make arm_validate_ns_entrypoint() common · 71e7a4e5
      Jeenu Viswambharan authored 
      

The function arm_validate_ns_entrypoint() validates a given non-secure
physical address. This function however specifically returns PSCI error
codes.

Non-secure physical address validation is potentially useful across ARM
platforms, even for non-PSCI use cases. Therefore make this function
common by returning 0 for success or -1 otherwise.

Having made the function common, make arm_validate_psci_entrypoint() a
wrapper around arm_validate_ns_entrypoint() which only translates return
value into PSCI error codes. This wrapper is now used where
arm_validate_ns_entrypoint() was currently used for PSCI entry point
validation.

Change-Id: Ic781fc3105d6d199fd8f53f01aba5baea0ebc310
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      71e7a4e5
    • Jeenu Viswambharan's avatar
      BL31: Add SDEI dispatcher · b7cb133e
      Jeenu Viswambharan authored 
      The implementation currently supports only interrupt-based SDEI events,
and supports all interfaces as defined by SDEI specification version
1.0 [1].

Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in
BL31.

Update user guide and porting guide. SDEI documentation to follow.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf



Change-Id: I758b733084e4ea3b27ac77d0259705565842241a
Co-authored-by: default avatarYousuf A <yousuf.sait@arm.com>
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      b7cb133e
    • Jeenu Viswambharan's avatar
      BL31: Program Priority Mask for SMC handling · 3d732e23
      Jeenu Viswambharan authored 
      

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: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      3d732e23
    • Jeenu Viswambharan's avatar
      BL31: Introduce Exception Handling Framework · 21b818c0
      Jeenu Viswambharan authored 
      

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: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      21b818c0
    • Jeenu Viswambharan's avatar
      GIC: Introduce API to get interrupt ID · 4ee8d0be
      Jeenu Viswambharan authored 
      

Acknowledging interrupt shall return a raw value from the interrupt
controller in which the actual interrupt ID may be encoded. Add a
platform API to extract the actual interrupt ID from the raw value
obtained from interrupt controller.

Document the new function. Also clarify the semantics of interrupt
acknowledge.

Change-Id: I818dad7be47661658b16f9807877d259eb127405
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      4ee8d0be
  13. 09 Nov, 2017 1 commit
  15. 08 Nov, 2017 14 commits
  17. 01 Nov, 2017 1 commit
  19. 31 Oct, 2017 2 commits
  21. 25 Oct, 2017 1 commit
  23. 24 Oct, 2017 1 commit
  25. 23 Oct, 2017 2 commits
  27. 17 Oct, 2017 3 commits