- 11 Jan, 2018 3 commits
-
-
Dimitris Papastamos authored
Change-Id: I504d3f65ca5829bc1f4ebadb764931f8379ee81f Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
If the CSV2 field reads as 1 then branch targets trained in one context cannot affect speculative execution in a different context. In that case skip the workaround on Cortex A75. Change-Id: I4d5504cba516a67311fb5f0657b08f72909cbd38 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
Invalidate the Branch Target Buffer (BTB) on entry to EL3 by temporarily dropping into AArch32 Secure-EL1 and executing the `BPIALL` instruction. This is achieved by using 3 vector tables. There is the runtime vector table which is used to handle exceptions and 2 additional tables which are required to implement this workaround. The additional tables are `vbar0` and `vbar1`. The sequence of events for handling a single exception is as follows: 1) Install vector table `vbar0` which saves the CPU context on entry to EL3 and sets up the Secure-EL1 context to execute in AArch32 mode with the MMU disabled and I$ enabled. This is the default vector table. 2) Before doing an ERET into Secure-EL1, switch vbar to point to another vector table `vbar1`. This is required to restore EL3 state when returning from the workaround, before proceeding with normal EL3 exception handling. 3) While in Secure-EL1, the `BPIALL` instruction is executed and an SMC call back to EL3 is performed. 4) On entry to EL3 from Secure-EL1, the saved context from step 1) is restored. The vbar is switched to point to `vbar0` in preparation to handle further exceptions. Finally a branch to the runtime vector table entry is taken to complete the handling of the original exception. This workaround is enabled by default on the affected CPUs. NOTE ==== There are 4 different stubs in Secure-EL1. Each stub corresponds to an exception type such as Sync/IRQ/FIQ/SError. Each stub will move a different value in `R0` before doing an SMC call back into EL3. Without this piece of information it would not be possible to know what the original exception type was as we cannot use `ESR_EL3` to distinguish between IRQs and FIQs. Change-Id: I90b32d14a3735290b48685d43c70c99daaa4b434 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 29 Nov, 2017 1 commit
-
-
Dimitris Papastamos authored
The Cortex A75 has 5 AMU counters. The first three counters are fixed and the remaining two are programmable. A new build option is introduced, `ENABLE_AMU`. When set, the fixed counters will be enabled for use by lower ELs. The programmable counters are currently disabled. Change-Id: I4bd5208799bb9ed7d2596e8b0bfc87abbbe18740 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 01 Jun, 2017 1 commit
-
-
David Wang authored
Both Cortex-A75 and Cortex-A55 CPUs use the ARM DynamIQ Shared Unit (DSU). The power-down and power-up sequences are therefore mostly managed in hardware, and required software operations are considerably simpler. Change-Id: I68b30e6e1ebe7c041d5e67f39c59f08575fc7ecc Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-