aboutsummaryrefslogtreecommitdiff
path: root/linux-user/m68k
diff options
context:
space:
mode:
authorPeter Maydell <peter.maydell@linaro.org>2014-04-15 19:18:39 +0100
committerPeter Maydell <peter.maydell@linaro.org>2014-04-17 21:34:03 +0100
commit8c6afa6ab158467d1938cc92022135bc7a872006 (patch)
tree828b37b0fba9f42d50862e612e65350d32b6170c /linux-user/m68k
parent00892383c9f5f663230921c6cf6b6d3a8a61b45b (diff)
target-arm: A64: Correctly fault FP/Neon if CPACR.FPEN set
For the A64 instruction set, the only FP/Neon disable trap is the CPACR FPEN bits, which may indicate "enabled", "disabled" or "disabled for EL0". Add a bit to the AArch64 tb flags indicating whether FP/Neon access is currently enabled and make the decoder emit code to raise exceptions on use of FP/Neon insns if it is not. We use a new flag in DisasContext rather than borrowing the existing vfp_enabled flag because the A32/T32 decoder is going to need both. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> --- I'm aware this is a rather hard to review patch; sorry. I have done an exhaustive check that we have fp access checks in all code paths with the aid of the assertions added in the next patch plus the code-coverage hack patch I posted to the list earlier. This patch is correct as of 09e037354 target-arm: A64: Add saturating accumulate ops (USQADD/SUQADD) which was the last of the Neon insns to be added, so assuming no refactoring of the code it should be fine.
Diffstat (limited to 'linux-user/m68k')
0 files changed, 0 insertions, 0 deletions