Re: [PATCH 1/4] target/arm/tcg/cpu-v7m.c: add cortex-m85 model

On Fri, 24 Jul 2026 at 19:11, Simon Xu <[email protected]> wrote:
>
> > The major reason IMHO to add a Cortex-M85 model would be to
> > have a CPU that supports M-profile PACBTI, so wouldn't
> > it be better to implement the feature first and then
> > add the CPU and the board model that uses it ?

> I understand your reasoning behind adding the feature first then the CPU/boards
> so that there's something to use the features. I looked through the patchew and
> saw that was how you handled it with the M55 CPU and v8.1-m features.
>
> To explain myself, this patch series was a part of my intern project at HPE. We
> currently have a fork of QEMU where we use it to emulate the HPE BMC. I am
> working on implementing the currently unavailable M85 CPU with the Custom
> Datapath Extension for internal use. I thought I could potentially upstream only
> the M85 CPU and related machines. I didn't include CDE because it was not fully
> polished and PACBTI because it was not super critical to my experimentations.
>
> I do agree there are no architectural differences between the M55 and M85 right
> now so I fully understand if this patch series is not sufficient for upstreaming.

I definitely think it's a great start and it's most of the work
that we'd need to do to be able to add a Cortex-M85 model.
We also had a series submitted which made an attempt at
the PACBTI implementation (though it only tried to do it
for user-mode, so it's also missing some parts):
https://lore.kernel.org/qemu-devel/[email protected]/

I've made review comments on the other parts of this patchset.
If you have time to work through those and respin, then I
might be able to find time to sort out the PACBTI part,
even if we can't commit the an555 board code immediately.
And even if not, we have these patches in the archive that
somebody else can pick up some day.

Incidentally, the custom datapath extensions would be a much
trickier thing to upstream, since by definition they're custom.
The Arm Fast Models handle these by letting the user supply
a plugin DLL that implements whatever the custom insns are,
but for QEMU external user-facing interfaces are always awkward
and it feels like specifying that in a workable way would be
a lot of effort for an extremely niche feature.

thanks
-- PMM