On Sun, 21 Apr 2024 at 06:40, Richard Henderson
<richard.henderson@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.