On 1/31/19 5:07 AM, Peter Maydell wrote:
> The {IOE, DZE, OFE, UFE, IXE, IDE} bits in the FPSCR/FPCR are for
> enabling trapped IEEE floating point exceptions (where IEEE exception
> conditions cause a CPU exception rather than updating the FPSR status
> bits). QEMU doesn't implement this (and nor does the hardware we're
> modelling), but for implementations which don't implement trapped
> exception handling these control bits are supposed to be RAZ/WI.
> This allows guest code to test for whether the feature is present
> by trying to write to the bit and checking whether it sticks.
>
> QEMU is incorrectly making these bits read as written. Make them
> RAZ/WI as the architecture requires.
>
> In particular this was causing problems for the NetBSD automatic
> test suite.
>
> Reported-by: Martin Husemann <mar...@netbsd.org>
> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
> ---
> Martin: this is a different fix to the one I suggested you test,
> because I realized we need to make these bits RAZ/WI in the aarch32
> FPSCR as well as the aarch64 FPCR, but it should have the same effect.
>
> General note: the difference between "RAZ/WI" and "RES0" is a bit
> subtle (see the Arm ARM glossary), but the main distinction is that
> RES0 bits can often be implemented as reads-as-written whilst
> RAZ/WI bits never can.
> ---
> target/arm/cpu.h | 6 ++++++
> target/arm/helper.c | 6 ++++++
> 2 files changed, 12 insertions(+)
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
r~
