Re: [PATCH] target/arm: fix MPIDR value for ARM CPUs with SMT

[Dorjoy Chowdhury <dorjoychy111@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

Hi Peter,

On Fri, May 31, 2024, 6:53 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Fri, 3 May 2024 at 17:53, Dorjoy Chowdhury <dorjoychy111@gmail.com>
> wrote:
> >
> > On Fri, May 3, 2024 at 10:28 PM Peter Maydell <peter.maydell@linaro.org>
> wrote:
> > >
> > > On Fri, 19 Apr 2024 at 19:31, Dorjoy Chowdhury <dorjoychy111@gmail.com>
> wrote:
> > > >
> > > > Some ARM CPUs advertise themselves as SMT by having the MT[24] bit
> set
> > > > to 1 in the MPIDR register. These CPUs have the thread id in
> Aff0[7:0]
> > > > bits, CPU id in Aff1[15:8] bits and cluster id in Aff2[23:16] bits in
> > > > MPIDR.
> > > >
> > > > On the other hand, ARM CPUs without SMT have the MT[24] bit set to 0,
> > > > CPU id in Aff0[7:0] bits and cluster id in Aff1[15:8] bits in MPIDR.
> > > >
> > > > The mpidr_read_val() function always reported non-SMT i.e., MT=0
> style
> > > > MPIDR value which means it was wrong for the following CPUs with SMT
> > > > supported by QEMU:
> > > >     - cortex-a55
> > > >     - cortex-a76
> > > >     - cortex-a710
> > > >     - neoverse-v1
> > > >     - neoverse-n1
> > > >     - neoverse-n2
> > >
> > > This has definitely turned out to be rather more complicated
> > > than I thought it would be when I wrote up the original issue
> > > in gitlab, so sorry about that.
> > >
> > > I still need to think through how we should deal with the
> > > interaction between what the CPU type implies about the MPIDR
> > > format and the topology information provided by the user.
> > > I probably won't get to that next week, because I'm on holiday
> > > for most of it, but I will see if I can at least make a start.
> > >
> >
> > No problem at all. Just let me know when you get to it. I will see if
> > I can fix it or ask if I need help then. Please enjoy your holidays.
>
> Hi -- this is a note to say that I haven't forgotten about this
> patch and the related issues, but I still haven't been able to
> make the time to think through how it ought to work yet :-(
>

No problem at all. Thanks for letting me know.

Regards,
Dorjoy

>

[-- Attachment #2: Type: text/html, Size: 3278 bytes --]