Re: cortex-a55/a75/a76 MPIDR_EL1 specifica

[Timofey Kutergin]

More like the opposite - proprietary software which does not yet have proper support for MT CPUs worked fine on QEMU but failed on hardware - so discrepancy was found.

This does not block anything right now, the question is more how closely qemu should follow hardware which it emulates...

BR

Timofey

On Thu, Dec 1, 2022 at 4:38 PM Peter Maydell <peter.maydell@linaro.org> wrote:

On Thu, 1 Dec 2022 at 10:55, Timofey Kutergin <tkutergin@gmail.com> wrote:
> After submitting a patch for cortex-a55 support and trying
> to run SMP on odroid-c4 I have found concern about mpidr_el1 register.
>
> cortex-a55 (and also a75/76/78) seem to be considered SMT CPUs
> with single SMT thread. As a result, they publish core numbers
> in AFF1 rather than in AFF0 and AFF0 is always zero. In the
> cortex-a55 TRM:
>
> Aff1, [11:8] Part of Affinity level 1. Third highest level affinity field.
>   CPUID. Identification number for each CPU in the Cortex-A55 cluster:
>   0x0 MP1: CPUID: 0. to
>   0x7 MP8: CPUID: 7.
> Aff0, [7:0]
>   Affinity level 0. The level identifies individual threads within a multi-threaded core. The
>   Cortex-A55 core is single-threaded, so this field has the value 0x00.
>
> Plus MT (bit 24) is set to 1.
>
> But it seems that qemu does not take it into account. Is this
> intentional? Does it make sense to change this behaviour to
> something closer to real CPU ?

I don't think it's intentional, it's just that when we wrote
the code to handle the MPIDR all the CPUs we emulated were
MT==0 and put their CPU number in the Aff0 field, so that's all
that the mpidr_read_val() function handles.

Of the CPUs we currently emulate, these ones set MT==1:
 * Cortex-A55
 * Cortex-A76
 * Neoverse-N1
(I don't know about the a64fx but would guess it is MT==0.)

Since we already have a couple of CPU models which we don't
get this right for, I don't think this needs to block the A55
support, but it would I think be nice to implement it correctly.
I guess I would do this via a bool ARMCPU::cpuid_in_aff1 similar to
the existing ARMCPU::mp_is_up, and making mpidr_read_val()
act appropriately. The awkward part is that this would mean
that across migration from an older QEMU version the guest
would see the MPIDR value change, which is probably bad.
So I guess we need a CPU property to suppress that and to
set that in the hw_compat_7_2 array (which will appear when
the 8.0 board types get added after 7.2 releases).

Did you see any guest-visible behaviour issues because of this
value being wrong ?

thanks
-- PMM