aarch64: expose SMT topology in cpu-map and allow smt: true - #6154
aarch64: expose SMT topology in cpu-map and allow smt: true#6154NathanChenNVIDIA wants to merge 5 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Please upload reports for the commit f36c092 to get more accurate results. Additional details and impacted files@@ Coverage Diff @@
## main #6154 +/- ##
==========================================
+ Coverage 82.99% 83.06% +0.07%
==========================================
Files 277 277
Lines 31311 31198 -113
==========================================
- Hits 25985 25915 -70
+ Misses 5326 5283 -43
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Hey @NathanChenNVIDIA thank you for the PR it seems the CI is currently failing with this error can we take a look at it? |
Emit a minimal cpu-map -- one cluster containing N cores -- and give each cpu node an explicit phandle so the cluster/core entries can reference it. Signed-off-by: Walter Wang <walterw@nvidia.com>
Extend the cpu-map node so that, when SMT is enabled, consecutive vCPUs (2*i, 2*i+1) are emitted as the two `thread` nodes of core `i` instead of as two independent cores. arm64 Linux derives thread siblings and "Thread(s) per core" purely from the device tree: parse_core() in drivers/base/arch_topology.c reads the `thread%d` child nodes, and store_cpu_topology() -- the fallback used when no cpu-map is present -- hardcodes thread_id to -1. MPIDR_EL1 is not consulted, so the cpu-map node alone is sufficient to expose SMT and no vCPU register state needs to change. With SMT disabled, or with a single vCPU, the emitted tree is unchanged. Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Remove the aarch64-specific rejection of smt: true in machine-config updates. The same validation rules as x86_64 now apply: vcpu_count must be 1 or even when SMT is enabled. Update the affected tests, API documentation, and changelog accordingly. Signed-off-by: Nathan Chen <nathanc@nvidia.com>
776c33e to
8df792d
Compare
Update integration tests to verify SMT can be configured on aarch64 and that guest CPU topology reflects the configured thread count. Add focused 2-vCPU and 4-vCPU cases that assert two threads per core. Signed-off-by: Nathan Chen <nathanc@nvidia.com>
8df792d to
8349695
Compare
Hi @JackThomson2 , thanks for taking a look. I made a fix to test_topology.py so that only the depth 6 hwloc output is updated in accordance with the associated changes to core count. I reverted the changes to depths 3, 4, and 5 because we do not yet have the associated updates to the device tree to advertise shared L1/L2 caches between sibling threads on ARM64. |
Changes
Reason
aarch64 guests currently have no cpu-map, so Linux treats each vCPU as its own core (thread_id = -1). SMT pairing on arm64 comes from the device tree (parse_core() in arch_topology.c), not from MPIDR, so describing thread siblings in cpu-map is enough for the guest to show a real SMT topology. The API already had an smt flag; rejecting it only on aarch64 blocked that topology from being configured.
Testing
On aarch64, a 2-vCPU guest with
smt: trueand guest kernel 6.1 reports:lscpu: CPU(s)=2, Thread(s) per core=2, Core(s) per cluster=1, Cluster(s)=1/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0-1/proc/device-tree/cpus/cpu-map/cluster0/core0/:thread0,thread1test_cpu_topologyskips on this host (kernel ≥ 6.14). The new ARM hwlocexpectations in that helper have not run here.
License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.PR Checklist
tools/devtool checkbuild --allto verify that the PR passesbuild checks on all supported architectures.
tools/devtool checkstyleto verify that the PR passes theautomated style checks.
how they are solving the problem in a clear and encompassing way.
in the PR.
CHANGELOG.md.If a specific issue led to this PR, this PR closes the issue.Runbook for Firecracker API changes.
integration tests.
I have linked an issue to every newTODO.rust-vmm.