The translation table walk for an ATS instruction can result in
various faults. In general these are just reported back via the
PAR_EL1 fault status fields, but in some cases the architecture
requires that the fault is turned into an exception:
* synchronous stage 2 faults of any kind during AT S1E0* and
AT S1E1* instructions executed from NS EL1 fault to EL2 or EL3
* synchronous external aborts are taken as Data Abort exceptions
(This is documented in the v8A Arm ARM DDI0487A.e D5.2.11 and G5.13.4.)
I noticed this by code inspection back last year sometime when
I was investigating a guest boot failure that turned out to be
due to an entirely different cause. I got about halfway through
trying to code up a fix before I realised it was irrelevant to
that bug. This patchset is just tidying up and completing that
work so it doesn't get lost.
Use of ATS insns in the cases where they might actually fault
is quite rare (obviously nobody sets up page tables where there's
no memory and they'll take external aborts, and even for the
"take a hyp trap for a stage 2 fault" case you need a setup
with a hypervisor and a guest that uses ATS insns, and Linux as
a guest doesn't use ATS at all. So my testing of this patchset
has been more "check it doesn't break things" rather than
actively finding and testing a use of the throw-an-exception path...
thanks
-- PMM
Peter Maydell (2):
target/arm: Allow ARMCPRegInfo read/write functions to throw
exceptions
target/arm: Take exceptions on ATS instructions when needed
target/arm/cpu.h | 6 ++-
target/arm/helper.c | 107 +++++++++++++++++++++++++++++++------
target/arm/translate-a64.c | 6 +++
target/arm/translate.c | 7 +++
4 files changed, 110 insertions(+), 16 deletions(-)
--
2.20.1
