On Wed, Oct 1, 2025 at 11:50 AM Peter Maydell <[email protected]> wrote:
>
> On Wed, 1 Oct 2025 at 09:55, Clément Chigot <[email protected]> wrote:
> > I'm wondering if the check [1] preventing "aarch64=off" without KMV is
> > still valid nowadays and if yes, if anyone has ideas about what are
> > the remaining blockers ?
>
> I did have a look at this a while back. A lot of it was "audit
> the code to make sure it's not relying on an assumption we will
> now be breaking", which I think I did most of. Some of the
> preliminary patches I already upstreamed (e.g. the elimination of
> the TYPE_AARCH64_CPU subclass). My TODO list from my notes is
> down to basically enforcing that the user doesn't select invalid
> option combinations:
>
>  * forbid weird prop configs like aarch64=off,sve=on if we don't already
>  * forbid -cpu max,aarch64=off for usermode
>  * forbid -cpu whatever,aarch64=off when it doesn't implement AArch32
>    at the relevant EL
>
> so my "allow aarch64=off" patch is a bit more complicated than
> just removing the check because it tries to enforce at least
> some of those.
>
> I also have some local patches which make an AArch64 CPU with
> aarch64=off manually zero out all the aa64_ ID reg values, so
> that feature checks on an aa64_foo feature don't pass. This
> lets us avoid having to go through and manually add extra
> "if AARCH64 && ..." clauses to all those feature checks.
> I need to rebase those and look at whether they're ready to
> send out.
>
> Other than that, I think it's mostly testing.

> I'll see if I can do that rebase and at least send it out as
> an RFC patchset.

Alright thanks a lot for all those details. No urgency at all though,
I was just wondering if executing 32 bit ARM on cortex-a53 was
feasible within QEMU.

Thanks,
Clément

> thanks
> -- PMM

Reply via email to