aarch64: expose SMT topology in cpu-map and allow smt: true - #6154
Open
NathanChenNVIDIA wants to merge 5 commits into
Open
aarch64: expose SMT topology in cpu-map and allow smt: true#6154NathanChenNVIDIA wants to merge 5 commits into
NathanChenNVIDIA wants to merge 5 commits into
Conversation
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>
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.