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

Patchew URL: https://patchew.org/QEMU/20190816125802.25877-1-peter.maydell@linaro.org/



Hi,

This series failed build test on s390x host. Please find the details below.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e

echo
echo "=== ENV ==="
env

echo
echo "=== PACKAGES ==="
rpm -qa

echo
echo "=== UNAME ==="
uname -a

CC=$HOME/bin/cc
INSTALL=$PWD/install
BUILD=$PWD/build
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --cc=$CC --prefix=$INSTALL
make -j4
# XXX: we need reliable clean up
# make check -j4 V=1
make install
=== TEST SCRIPT END ===




The full log is available at
http://patchew.org/logs/20190816125802.25877-1-peter.maydell@linaro.org/testing.s390x/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com

On Fri, 16 Aug 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> 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...

I'm told that Xen for Arm makes more active use of ATS
instructions, so I've cc'd a few Xen people -- do any
of you have handy testing setups to try running Xen in
emulation under QEMU? Configs where the guest (EL1) actually
uses ATS instructions are the particularly interesting point
for this patchset.

(if there's a good set of instructions for creating a test
image I could probably add it to the ad-hoc set of things
I sometimes test with.)

> 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(-)

thanks
-- PMM

On Mon, Aug 19, 2019 at 01:44:37PM +0100, Peter Maydell wrote:
> On Fri, 16 Aug 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > 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...
> 
> I'm told that Xen for Arm makes more active use of ATS
> instructions, so I've cc'd a few Xen people -- do any
> of you have handy testing setups to try running Xen in
> emulation under QEMU? Configs where the guest (EL1) actually
> uses ATS instructions are the particularly interesting point
> for this patchset.
> 
> (if there's a good set of instructions for creating a test
> image I could probably add it to the ad-hoc set of things
> I sometimes test with.)


Hi,

All tests passed.

Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>

Cheers,
Edgar

On Mon, Aug 19, 2019 at 01:44:37PM +0100, Peter Maydell wrote:
> On Fri, 16 Aug 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > 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...
> 
> I'm told that Xen for Arm makes more active use of ATS
> instructions, so I've cc'd a few Xen people -- do any
> of you have handy testing setups to try running Xen in
> emulation under QEMU? Configs where the guest (EL1) actually
> uses ATS instructions are the particularly interesting point
> for this patchset.
> 
> (if there's a good set of instructions for creating a test
> image I could probably add it to the ad-hoc set of things
> I sometimes test with.)
> 

Yes, I'm not very up to date with the Xen code but it used to
be the case that Xen used ATS a fair bit. We have some other
tests that use it but they don't rely on exceptions IIRC.

I'll take your patches and test them with our internal testsuites, including Xen images.

I may also be able to find a Xen image I can share that works with upstream QEMU.
Stefano may have something in his pocket already?

Cheers,
Edgar