This is something that we've talked about for quite some time,
having separate "max" cpu types for Armv{8,9}, because Armv9
prohibits some deprecated Armv8 features.  Retaining all features
simultaneously has the potential to cause confusion.

Changes for v2:
  - Re-reorg cpu_max_initfn, avoiding the build failures without tcg.
  - Move aarch32 tcg parts of cpu_max_initfn to tcg/cpu32.c.
  - Separate patch updating feature comments in aarch64_max_tcg_initfn.
  - Do not avoid aa32_max_features for v9 -- the registers still exist
    and describe the features that might be present at EL0.

r~

Richard Henderson (10):
  target/arm: Tidy cpu_max_initfn
  target/arm: Pass ARMCPU to aarch64_aa32_a57_init
  target/arm: Pass aarch64_enabled to aarch64_aa32_a57_init
  target/arm: Sink aarch64_aa32_a57_init into aarch64_max_tcg_initfn
  target/arm: Split out aarch32_max_tcg_init
  target/arm: Move aa32_max_features to tcg/cpu32.c
  target/arm: Introduce cpu types max-v8 and max-v9
  target/arm: Use -cpu max-v8 with aarch64=off
  target/arm: Annotate arch revisions in aarch64_max_tcg_initfn
  target/arm: Separate cpu types max-v8 and max-v9

 target/arm/internals.h                        |   5 +-
 hw/arm/sbsa-ref.c                             |   2 +
 hw/arm/virt.c                                 |   2 +
 target/arm/cpu-max.c                          | 131 +-----
 target/arm/cpu64.c                            |   2 +-
 target/arm/tcg/cpu32.c                        | 111 +++++
 target/arm/tcg/cpu64.c                        | 397 +++++++++++-------
 target/arm/tcg/stubs32.c                      |   2 +-
 tests/qtest/arm-cpu-features.c                |   4 +-
 docs/system/arm/emulation.rst                 |  11 +-
 .../aarch64/test_virt_aarch64_off.py          |   4 +-
 11 files changed, 379 insertions(+), 292 deletions(-)

-- 
2.43.0

On Wed, 12 Aug 2026 at 21:44, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> This is something that we've talked about for quite some time,
> having separate "max" cpu types for Armv{8,9}, because Armv9
> prohibits some deprecated Armv8 features.  Retaining all features
> simultaneously has the potential to cause confusion.
>
> Changes for v2:
>   - Re-reorg cpu_max_initfn, avoiding the build failures without tcg.
>   - Move aarch32 tcg parts of cpu_max_initfn to tcg/cpu32.c.
>   - Separate patch updating feature comments in aarch64_max_tcg_initfn.
>   - Do not avoid aa32_max_features for v9 -- the registers still exist
>     and describe the features that might be present at EL0.
>
> r~
>
> Richard Henderson (10):
>   target/arm: Tidy cpu_max_initfn
>   target/arm: Pass ARMCPU to aarch64_aa32_a57_init
>   target/arm: Pass aarch64_enabled to aarch64_aa32_a57_init
>   target/arm: Sink aarch64_aa32_a57_init into aarch64_max_tcg_initfn
>   target/arm: Split out aarch32_max_tcg_init
>   target/arm: Move aa32_max_features to tcg/cpu32.c

I've applied these (1..6)...

>   target/arm: Annotate arch revisions in aarch64_max_tcg_initfn

and this (9) with the minor comment fixups I noted (but not
doing anything about AA64ISAR.API or re-sorting the out of
order ID reg field setting) to target-arm.next.

thanks
-- PMM

On Mon, 17 Aug 2026 at 16:01, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Wed, 12 Aug 2026 at 21:44, Richard Henderson
> <richard.henderson@linaro.org> wrote:
> >
> > This is something that we've talked about for quite some time,
> > having separate "max" cpu types for Armv{8,9}, because Armv9
> > prohibits some deprecated Armv8 features.  Retaining all features
> > simultaneously has the potential to cause confusion.
> >
> > Changes for v2:
> >   - Re-reorg cpu_max_initfn, avoiding the build failures without tcg.
> >   - Move aarch32 tcg parts of cpu_max_initfn to tcg/cpu32.c.
> >   - Separate patch updating feature comments in aarch64_max_tcg_initfn.
> >   - Do not avoid aa32_max_features for v9 -- the registers still exist
> >     and describe the features that might be present at EL0.
> >
> > r~
> >
> > Richard Henderson (10):
> >   target/arm: Tidy cpu_max_initfn
> >   target/arm: Pass ARMCPU to aarch64_aa32_a57_init
> >   target/arm: Pass aarch64_enabled to aarch64_aa32_a57_init
> >   target/arm: Sink aarch64_aa32_a57_init into aarch64_max_tcg_initfn
> >   target/arm: Split out aarch32_max_tcg_init
> >   target/arm: Move aa32_max_features to tcg/cpu32.c
>
> I've applied these (1..6)...
>
> >   target/arm: Annotate arch revisions in aarch64_max_tcg_initfn
>
> and this (9) with the minor comment fixups I noted (but not
> doing anything about AA64ISAR.API or re-sorting the out of
> order ID reg field setting) to target-arm.next.

Also, once we have a max-v9 we should fix up the slightly
bodged GICv5 property handling: currently we register
the has-gcie property for v8 + AARCH64, but we should update
that to only register it for a v9 CPU. (Q: how should we detect
that we have a v9 CPU ? Do we need an ARM_FEATURE_V9?)
Then we can remove the code that does 'Downgrade "AArch32 and AArch64"
to "AArch64"' when has_gcie is true. I can do that after this series
lands, if you prefer.

thanks
-- PMM

On 8/17/26 08:04, Peter Maydell wrote:
> Also, once we have a max-v9 we should fix up the slightly
> bodged GICv5 property handling: currently we register
> the has-gcie property for v8 + AARCH64, but we should update
> that to only register it for a v9 CPU. (Q: how should we detect
> that we have a v9 CPU ? Do we need an ARM_FEATURE_V9?)
> Then we can remove the code that does 'Downgrade "AArch32 and AArch64"
> to "AArch64"' when has_gcie is true. I can do that after this series
> lands, if you prefer.
ARM_FEATURE_V9 is certainly the easiest way, and I'd be happy with that.


r~