On Wed, 1 May 2024 at 19:08, Marcin Juszkiewicz <marcin.juszkiew...@linaro.org> wrote: > > 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.
The U bit is a red herring here -- it indicates a property of the implementation, not of the topology. It is an almost obsolete bit that might have been useful on 32-bit cores (eg the A9 had a UP version and an MP version; we only implement the MP version, and the Cortex-R5 sets the U bit). I think any modern CPU will have U=0, whether it happens to be the only CPU in the system or not. > 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]. I think the answer here is "guest software doesn't rely on the Aff fields to indicate topology". See eg this patch from back in 2020 to the kernel: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20200829130016.26106-1-valentin.schnei...@arm.com/ (now kernel commit 3102bc0e6ac752cc5) which notes that the amount of implementation leniency in the Aff* definitions and some of the odd stuff that has been shipped in practice means that you can't get useful topology information out of the MPIDR (which is why we provide it in the ACPI/dtb). On the QEMU side I guess we should strive to set up the MPIDR fields to something plausibly matching the topology as defined by the user on the command line. Unanswered questions: * I guess we need some kind of back-compat thing where for old machine types we continue to report the old MPIDR * what are the constraints on the Aff* fields (eg that kernel commit suggests Aff0 shouldn't be > 15)? * should user attempts to eg ask for a topology with threads > 1 but a CPU type which isn't multithreaded be an error? (What is the existing QEMU x86 practice here?) thanks -- PMM
