Support more ARM CPUs

[Christophe Lyon]

Hi,

This is an enhancement request, rather than a bug report.

After some discussions/presentations during the last Linaro Connect (SFO17), I understand that it may be easy to add support for more ARM CPUs in QEMU. I am interested in user-mode, if that matters.

I'm primarily using QEMU for GCC validations, and I'd like to make sure that GCC doesn't generate instructions not supported by the CPU it's supposed to generate code for.

I'd like to have:
cortex-m0
cortex-m4
cortex-m7
cortex-m23
cortex-m33

cortex-a35
cortex-a53
cortex-a57

Is it possible?
Is it the right place to ask?
Should I file separate requests for each?

Thanks

[Peter Maydell (pmaydell)]

M0 is hard, because it's v6M which we don't support. M4 we already have (but only the no-fpu variant). M7 we don't currently have -- what would be the differences from M4? M33 is in the works (it's v8M). M23 is harder, because it's v8M-baseline which is the v8M equivalent to v6M. A53 and A57 we already have. How would A35 differ from A53/A57 ?

[Peter Maydell (pmaydell)]

PS: in general I wouldn't unconditionally trust that QEMU emulating CPU X definitely does not implement any instructions that CPU X doesn't have -- no real world code will notice, and we don't have any mechanism to automatically verify that we didn't accidentally forget to conditionalize an instruction on an architecture feature.

[Christophe Lyon (christophe-lyon)]

Thanks for PS, I thought QEMU was stricter than that.

Regarding M7 vs M$ or A35 vs A53/A57, even though there's no functional difference, it would be convenient in Makefiles to have CPU=cortex-a53, and use $(CPU) to expand GCC and QEMU options, without having to guess which CPU I should use for QEMU that would match the one I pass to GCC.

Regarding v[68]M, are there any plans to add support for these variants to QEMU?

[Peter Maydell (pmaydell)]

On 16 October 2017 at 14:16, Christophe Lyon
<email address hidden> wrote:
> Thanks for PS, I thought QEMU was stricter than that.

Well, I hope we get it right, and we'll treat cases where
we get it wrong as bugs, but we're not testing...

> Regarding v[68]M, are there any plans to add support for these variants
> to QEMU?

v8M we're working on. v6M we have no plans for currently.

thankns
-- PMM

[Peter Maydell (pmaydell)]

We now support Cortex-M0 (v6M) and Cortex-M33 (v8M mainline). We don't have Cortex-M7, Cortex-M23 (v8M baseline) or Cortex-A35.

In general, adding an extra CPU to QEMU really requires us to have a decent use-case for it, probably including a board model for it, especially for the M-profile CPUs. There are a lot of CPUs out there and I'm not too keen on adding large numbers of them unless there's a real need.

I'm going to close this bug report because I don't think it really adds anything to have it sitting open indefinitely.

[Christophe Lyon (christophe-lyon)]

Regarding Cortex-M7, I've noticed that unlike Cortex-M4, it supports double precision floating-point. Is DP supported by qemu?

[Peter Maydell (pmaydell)]

Yes, QEMU supports DP (I actually had to go to some lengths to disable the DP support for the M4 :-))

[Christophe Lyon (christophe-lyon)]

How do I activate it since --cpu cortex-m7 isn't supported?

[Peter Maydell (pmaydell)]

You can't for an M-profile CPU. It would work without any further coding beyond getting the ID register values right if we had a Cortex-M7 model, though.

[Christophe Lyon (christophe-lyon)]

It seemed "easy" to add cortex-m7 based on cortex-m4 (copy m4 description, update ID register values), but I realized that QEMU does not support FPv5 which not only supports DP, but also adds new instructions that QEMU does not handle yet (see section A2.5 of the ARMv7-M ARM).

* Are there plans to implement them?
* If not, how difficult is it? (for a developer not very familiar with the QEMU code base)

[Richard Henderson (rth)]

They are implemented, because they also appear in A-profile.
We just need to set the corresponding MVFR field to enable them.

Setting MVFR2.FPMISC = 4 will do the job, I believe.

[Christophe Lyon (christophe-lyon)]

Good news, I thought at least some of them were not implemented because for instance I couldn't find where VRINTA is handled (I noticed code for NEON_2RM_VRINTA, but I thought there should be something in vfp.decode for VRINT[ANPM])