W dniu 22.04.2024 o 17:21, Richard Henderson pisze:
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.
Looking at the TRM, Neoverse-E1 is "MT is set, actual SMT,
Aff0 is the thread" (Aff0 can be 0 or 1). We just don't
model that CPU type yet. But we should probably make
sure we don't block ourselves into a corner where that
would be awkward -- I'll have a think about this and
look at what x86 does with the topology info.
I'm suggesting that we set things up per -smp, and if the user chooses a
-cpu value for which that topology doesn't make sense, we do it anyway
and let them keep both pieces.
Aff[0-3] are 8 bit each. On those cpus where they exist.
So "-smp 512" (maximum allowed for sbsa-ref) would need to be split to 2
clusters by 256 cores or 64 clusters of 8 cores each like it is today so
it is backward compatible with whatever assumption firmware/OS does.
But if we go for 'newer, better MPIDR_EL1' then maybe it is time to set
U bit [30] if "-smp X,sockets=Y" where Y > 1? Or when NUMA config with
multiple cpu nodes are setup.
Also a way to know which AffX fields to check on firmware/OS side would
be nice. A57/72 use Aff[1-2], N1+ use Aff[0-3]. Sure, it can be checked
by going through cores, reading then MPIDR_EL1 and if 7:0 has same value
on all of them then check Aff[1-3], otherwise Aff[1-2].
