oxidecomputer / oxidecomputer/propolis
VMs should not have vCPU-many sockets
@iximeow is already working on this.
Since Sep 6, 2025.
- Dominant language
- Rust
- Stars
- 270
- Forks
- 42
- Avg merge
- 4d 5h
- Merged PRs (30d)
- 6
Description
this is a bit silly:
debian@debian-11:~$ likwid-topology -g
--------------------------------------------------------------------------------
CPU name: AMD EPYC 7713P 64-Core Processor
CPU type: AMD K19 (Zen3) architecture
CPU stepping: 1
********************************************************************************
Hardware Thread Topology
********************************************************************************
Sockets: 8
Cores per socket: 1
Threads per core: 1
I (and I think everyone else) thought we're emulating a single-socket machine until we intend otherwise, with vCPU-many cores and one or two threads per core. Looking into #921 I noticed we discard leaf Ext1E and then never repopulate it for the VM's CPU count, but we never clear the TopologyExtensions bit, so the all-zero leftovers is declared to be faithful. That gets us vCPU-many sockets, oops.
RFD 314 and https://github.com/oxidecomputer/omicron/pull/8728 in particular set leaf 8000_001E to have two threads per core, but I'm actually not sure that gets us to one socket with vCPU-many-(or vCPU/2) cores. Either way, out of the box Propolis should reconstruct the CPUID leaf StdB/Ext1E that it very eagerly discards.
This will change the CPUID profile of guests as-is, but I think that's good - I'm a little surprised that OSes are as nice about this as they are!
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.