[PATCH 00/11] target/arm: Fix some Neon trapping corner cases

Peter Maydell posted 11 patches 3 weeks, 2 days ago
Only 6 patches received!
target/arm/cpu.c                |   2 +-
target/arm/cpu.h                |  16 ++++
target/arm/helper.c             |  93 +++++++++++++++++++----
target/arm/internals.h          |   8 ++
target/arm/syndrome.h           |  28 +++++--
target/arm/tcg/cpu32-system.c   |   4 +
target/arm/tcg/hflags.c         |  93 +++++++++++++++++++++++
target/arm/tcg/translate-a32.h  |   1 +
target/arm/tcg/translate-a64.c  |   2 +-
target/arm/tcg/translate-neon.c |  74 +++++++++---------
target/arm/tcg/translate-vfp.c  | 131 +++++++++++++++++++++-----------
target/arm/tcg/translate.c      |   2 +
target/arm/tcg/translate.h      |   2 +
13 files changed, 351 insertions(+), 105 deletions(-)
[PATCH 00/11] target/arm: Fix some Neon trapping corner cases
Posted by Peter Maydell 3 weeks, 2 days ago
There are a couple of corner cases in trapping of A32 Neon insns that
have been kicking around as issues in the bug tracker for ages; I
got round to fixing them today. They're related in that they both
need us to distinguish Neon from VFP insns at the point of checking
for traps.

The first one is a bug, where we aren't reporting the correct syndrome
information for A32 VFP and Neon insns that are trapped to AArch32
EL2. These have COPROC and TA fields in the syndrome which we weren't
filling in correctly. (When the trap goes to AArch64 EL2, the fields
are RES0, which we do get right.) It's pretty obscure, though, and I
know of no guest software which might actually care about distinguishing
Neon from VFP insns in the hyp trap handler, so I don't think it worth
backporting to stable.

The second one is a missing optional feature: there is a CPACR.ASEDIS
bit that lets software force Neon insns to UNDEF, and also a hyp trap
bit HCPTR.TACE that lets the hypervisor force Neon insns to trap to
it. These are architecturally optional but in practice implemented on
all CPUs except for the Cortex-A8.

The third one is another missing optional feature: CPACR.D32DIS lets
software force VFP (not Neon) insns that use D16..D31 to trap. This
is rather obscure as it goes away in v8A, and of the CPUs we implement
it's only present in the Cortex-A7 and Cortex-A9.

-- PMM

Peter Maydell (11):
  target/arm: Separate out Neon from VFP access checks
  target/arm: Separate syndrome functions for A32 and A64
  target/arm: Report correct syndrome to AArch32 EL2 for trapped
    Neon/VFP insns
  target/arm: Define fields for NSACR
  target/arm: Handle NSACR.NSASEDIS in CPACR accesses
  target/arm: Handle NSACR.NSASEDIS in HCPTR accesses
  target/arm: Update confusing comment in cpacr_write()
  target/arm: Add new feature ARM_FEATURE_NO_NEON_TRAPS
  target/arm: Implement CPACR.ASEDIS and HCPTR.TASE
  target/arm: Pull VFP "can we use D16-D31" checks out into a function
  target/arm: Implement CPACR.D32DIS

 target/arm/cpu.c                |   2 +-
 target/arm/cpu.h                |  16 ++++
 target/arm/helper.c             |  93 +++++++++++++++++++----
 target/arm/internals.h          |   8 ++
 target/arm/syndrome.h           |  28 +++++--
 target/arm/tcg/cpu32-system.c   |   4 +
 target/arm/tcg/hflags.c         |  93 +++++++++++++++++++++++
 target/arm/tcg/translate-a32.h  |   1 +
 target/arm/tcg/translate-a64.c  |   2 +-
 target/arm/tcg/translate-neon.c |  74 +++++++++---------
 target/arm/tcg/translate-vfp.c  | 131 +++++++++++++++++++++-----------
 target/arm/tcg/translate.c      |   2 +
 target/arm/tcg/translate.h      |   2 +
 13 files changed, 351 insertions(+), 105 deletions(-)

-- 
2.43.0
Re: [PATCH 00/11] target/arm: Fix some Neon trapping corner cases
Posted by Peter Maydell 2 weeks, 6 days ago
On Thu, 2 Jul 2026 at 19:40, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> There are a couple of corner cases in trapping of A32 Neon insns that
> have been kicking around as issues in the bug tracker for ages; I
> got round to fixing them today. They're related in that they both
> need us to distinguish Neon from VFP insns at the point of checking
> for traps.
>
> The first one is a bug, where we aren't reporting the correct syndrome
> information for A32 VFP and Neon insns that are trapped to AArch32
> EL2. These have COPROC and TA fields in the syndrome which we weren't
> filling in correctly. (When the trap goes to AArch64 EL2, the fields
> are RES0, which we do get right.) It's pretty obscure, though, and I
> know of no guest software which might actually care about distinguishing
> Neon from VFP insns in the hyp trap handler, so I don't think it worth
> backporting to stable.
>
> The second one is a missing optional feature: there is a CPACR.ASEDIS
> bit that lets software force Neon insns to UNDEF, and also a hyp trap
> bit HCPTR.TACE that lets the hypervisor force Neon insns to trap to
> it. These are architecturally optional but in practice implemented on
> all CPUs except for the Cortex-A8.
>
> The third one is another missing optional feature: CPACR.D32DIS lets
> software force VFP (not Neon) insns that use D16..D31 to trap. This
> is rather obscure as it goes away in v8A, and of the CPUs we implement
> it's only present in the Cortex-A7 and Cortex-A9.
>
> -- PMM
>
> Peter Maydell (11):
>   target/arm: Separate out Neon from VFP access checks
>   target/arm: Separate syndrome functions for A32 and A64
>   target/arm: Report correct syndrome to AArch32 EL2 for trapped
>     Neon/VFP insns
>   target/arm: Define fields for NSACR

I'm going to take these four patches into target-arm.next, since
the "wrong syndrome" is a bug, and the fourth patch is an
uncontroversial little cleanup.

>   target/arm: Handle NSACR.NSASEDIS in CPACR accesses
>   target/arm: Handle NSACR.NSASEDIS in HCPTR accesses
>   target/arm: Update confusing comment in cpacr_write()
>   target/arm: Add new feature ARM_FEATURE_NO_NEON_TRAPS
>   target/arm: Implement CPACR.ASEDIS and HCPTR.TASE
>   target/arm: Pull VFP "can we use D16-D31" checks out into a function
>   target/arm: Implement CPACR.D32DIS

These ones had review issues I need to address, and they're
more on the "feature" side than the "bug fix" side, so they've
missed the boat for 11.1. I'll do a v2 at some point so we
can get them into 11.2.

thanks
-- PMM