On Sun, 21 Apr 2024 at 06:40, Richard Henderson
<richard.hender...@linaro.org> wrote:
> > --- a/target/arm/cpu.c
> > +++ b/target/arm/cpu.c
> > @@ -1314,8 +1314,18 @@ static void arm_cpu_dump_state(CPUState *cs, FILE
> > *f, int flags)
> > }
> > }
> >
> > -uint64_t arm_build_mp_affinity(int idx, uint8_t clustersz)
> > +uint64_t arm_build_mp_affinity(ARMCPU *cpu, int idx, uint8_t clustersz)
> > {
> > + if (cpu->has_smt) {
> > + /*
> > + * Right now, the ARM CPUs with SMT supported by QEMU only have
> > + * one thread per core. So Aff0 is always 0.
> > + */
>
> Well, this isn't true.
>
> -smp
> [[cpus=]n][,maxcpus=maxcpus][,drawers=drawers][,books=books][,sockets=sockets]
>
> [,dies=dies][,clusters=clusters][,cores=cores][,threads=threads]
>
> I would expect all of Aff[0-3] to be settable with the proper topology
> parameters.
As I understand it the MPIDR value is more or less independent
of the topology information as presented to the guest OS.
The options to the -smp command set the firmware topology
information, which doesn't/shouldn't affect the reported
MPIDR values, and in particular shouldn't change whether
the CPU selected has the MT bit set or not.
For Arm's CPUs they fall into two categories:
* older ones don't set MT in their MPIDR, and the Aff0
field is effectively the CPU number
* newer ones do set MT in their MPIDR, but don't have
SMT, so their Aff0 is always 0 and their Aff1
is the CPU number
Of all the CPUs we model, none of them are the
architecturally-permitted "MT is set, CPU implements
actual SMT, Aff0 indicates the thread in the CPU" type.
For TCG all the topology info is pretty irrelevant anyway:
if the user wants to tell the guest OS that it should
do NUMA partitioning (assuming threads or otherwise),
that's up to them.
thanks
-- PMM
