Skip to content

Specialize CPUID leaf 8000_001E reasonably #959

@iximeow

Description

@iximeow

https://github.com/oxidecomputer/propolis/blob/master/lib/propolis/src/cpuid.rs#L241-L247 includes this TODO:

                if *topo == TopoKind::Ext1E {
                    // TODO: clear the TopologyExtensions bit in leaf 8000_0001
                    // since we've just discarded the leaf. Change this *after*
                    // the wholesale move to fixed CPUID leaves (Omicron#8728)
                    // so the typical case just never has this bit set and a
                    // change here is not an additional guest-visible change.
                }

This still needs doing, and not having done it means that Linux guests try to use the initial extended APIC ID from 8000_001E[EAX] after the CPUID specializer discarded the leaf. Then it reads 0 which disagrees with the initial ID it reads from the APIC and reports:

[Firmware Bug]: CPU   17: APIC ID mismatch. CPUID: 0x0000 APIC: 0x0011

.. well, the "firmware" is right here. This predated #941 and is a newish warning in Linux as of kernel 6.12 (commit 52128a7a21), which happens to be what Debian 13 shipped and where I noticed the message. There don't appear to be any actual issues in the VM afterward.

Since we specialize CPUID topology bits after getting a set of CPUID leaves Omicron#8728 doesn't really have much bearing here - we were wrong before, wrong after, and explicit CPU profiles mostly just gives us a nice way to add this leaf.

Meanwhile, for the initial Turin CPU profile I intend to populate ThreadsPerComputeUnit to reflect SMT, and discarding this leaf means we don't do that.

Metadata

Metadata

Assignees

Labels

bugSomething that isn't working.guest-osRelated to compatibility and/or functionality observed by guest software.

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions