1. 30 Nov, 2017 1 commit
    • David Cunado's avatar
      Enable SVE for Non-secure world · 1a853370
      David Cunado authored
      
      
      This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set
      to one EL3 will check to see if the Scalable Vector Extension (SVE) is
      implemented when entering and exiting the Non-secure world.
      
      If SVE is implemented, EL3 will do the following:
      
      - Entry to Non-secure world: SIMD, FP and SVE functionality is enabled.
      
      - Exit from Non-secure world: SIMD, FP and SVE functionality is
        disabled. As SIMD and FP registers are part of the SVE Z-registers
        then any use of SIMD / FP functionality would corrupt the SVE
        registers.
      
      The build option default is 1. The SVE functionality is only supported
      on AArch64 and so the build option is set to zero when the target
      archiecture is AArch32.
      
      This build option is not compatible with the CTX_INCLUDE_FPREGS - an
      assert will be raised on platforms where SVE is implemented and both
      ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1.
      
      Also note this change prevents secure world use of FP&SIMD registers on
      SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on
      such platforms unless ENABLE_SVE_FOR_NS is set to 0.
      
      Additionally, on the first entry into the Non-secure world the SVE
      functionality is enabled and the SVE Z-register length is set to the
      maximum size allowed by the architecture. This includes the use case
      where EL2 is implemented but not used.
      
      Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      1a853370
  2. 29 Nov, 2017 5 commits
  3. 24 Nov, 2017 2 commits
  4. 23 Nov, 2017 4 commits
  5. 22 Nov, 2017 3 commits
  6. 21 Nov, 2017 2 commits
  7. 20 Nov, 2017 8 commits
  8. 17 Nov, 2017 2 commits
  9. 15 Nov, 2017 3 commits
    • 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
    • Antonio Nino Diaz's avatar
      SPM: Fix SP_COMMUNICATE_AARCH32/64 parameters · d6b532b5
      Antonio Nino Diaz authored
      
      
      The parameters passed to the Secure world from the Secure Partition
      Manager when invoking SP_COMMUNICATE_AARCH32/64 were incorrect, as well
      as the checks done on them.
      
      Change-Id: I26e8c80cad0b83437db7aaada3d0d9add1c53a78
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      d6b532b5
    • Antonio Nino Diaz's avatar
      SPM: Fix calculation of max page granularity · 9efd6e5c
      Antonio Nino Diaz authored
      
      
      The code was incorrectly reading from ID_AA64PRF0_EL1 instead of
      ID_AA64MMFR0_EL1 causing the supported granularity sizes returned by the
      code to be wrong.
      
      This wasn't causing any problem because it's just used to check the
      alignment of the base of the buffer shared between Non-secure and Secure
      worlds, and it was aligned to more than 64 KiB, which is the maximum
      granularity supported by the architecture.
      
      Change-Id: Icc0d949d9521cc0ef13afb753825c475ea62d462
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      9efd6e5c
  10. 14 Nov, 2017 1 commit
  11. 13 Nov, 2017 9 commits