Re: [PATCH v2 00/10] target/arm: Introduce cpu types max-v8 and max-v9

On Mon, 17 Aug 2026 at 16:01, Peter Maydell <[email protected]> wrote:
>
> On Wed, 12 Aug 2026 at 21:44, Richard Henderson
> <[email protected]> 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