Features/CPUModels

Summary

This page was about the feature of "externally-configurable" CPU models, but its scope was gradually changed to discussion about the design of the CPU code, the CPU model system. The old "cpudef" config section was deprecated, so the original description doesn't apply anymore.

Owner

• Name: Eduardo Habkost
• Email: ehabkost@redhat.com

Detailed Summary

The old "cpudef" config section was deprecated because there are expectations that QEMU is going to provide the CPU model list, and will keep migration compatibility using machine-types, and keeping machine-type compatibility (something that is inside the QEMU C code) while keeping the CPU model definitions external would be a dependency/layering violation. Now both CPU model definitions and per-machine-type CPU-model compatibility code are inside the QEMU C code.

The pseudo CPUID flag 'check' when appearing in the command line feature flag list will warn when feature flags (either implicit in a cpu model or explicit on the command line) would have otherwise been quietly unavailable to a guest:

   # qemu-system-x86_64 ... -cpu Nehalem,check
   warning: host cpuid 0000_0001 lacks requested flag 'sse4.2|sse4_2' [0x00100000]
   warning: host cpuid 0000_0001 lacks requested flag 'popcnt' [0x00800000]

A similar 'enforce' pseudo flag exists which in addition to the above causes qemu to error exit if requested flags are unavailable.

Roadmap for QEMU 1.3

Below current tasks/series are planned for QEMU 1.3:

• kvm_arch_get_supported_cpuid() refactor (ehabkost)
• CPU properties (Igor Mammedov)

 * Being redone to use static properties

• Allow changing of Hypervisor CPUIDs (Don Slutz)
• CPU model classes (ehabkost) (to be rebased/resubmitted)
• Make CPU child of DeviceState (there are 3 proposals today, not sure which one will be adopted)
• APIC-ID-related topology fixes (ehabkost) (to be rebased/cleaned-up/resubmitted)

Pending (not yet submitted) work by ehabkost:

• Run GET_SUPPORTED_CPUID only once (ehabkost)
• CPU feature_words refactor (ehabkost)
• -cpu check/enforce use GET_SUPPORTED_CPUID (ehabkost)
• -cpu host use GET_SUPPORTED_CPUID (ehabkost)
• add feature flag name list for CPUID 7

Already done

• Drop "-cpu ?dump" (Peter Maydell)
• Move CPU models to C code (ehabkost)
• Eliminate cpudef config section support (ehabkost)
• "unduplicate feature names" series (ehabkost)

Current Issues and proposed changes

Allowing CPU models to be updated

We need a mechanism to allow the existing CPU models on Qemu to be updated, without making guest-visible changes for existing Virtual Machines, when migrating to a new version.

Examples

Examples where CPU model updates are necessary and have to be deployed to users:

• The Nehalem CPU model currently has the wrong "level" value, making CPU topology information unavailable.
• The CPUID PMU leaf was added on Qemu 1.1, but it is not supposed to be visible to guests running using -M pc-1.0
• New features are implemented by KVM and we may want to add them to existing models (e.g. SandyBridge may need to have tsc-deadline added)

Requirements

• A different CPU will be visible to the guest depending on the machine-type chosen.
  • That means that "-M pc-1.0 -cpu Nehalem" will be different from "-M pc-1.1 -cpu Nehalem"
  • Rationale:
    • The meaning of "-M pc-1.0 -cpu Nehalem" can't be changed or it will change existing guests
    • The meaning of "-M pc-1.1 -cpu Nehalem" needs to be different from the pc-1.0 one, otherwise we would be stuck with a broken "Nehalem" model forever

Current design proposal

• CPU model definitions are going to be moved to C code, so we can easily add compatibility code to them if necessary
• CPUs now QOM objects
• CPU objects will become DeviceState children, so we can use the qdev global-property compatibility system
• CPU models will become separate classes, so per-CPU-model compatibility properties can be used on machine-type definitions

There was an old proposal for "versioning" CPU models, but that proposal was rejected in favor of the above.

Probing of CPU model details

libvirt don't write CPU definitions from scratch, so it will reuse the CPU models from /usr/share. But it needs to probe for details of the CPU models.

Requirements

A detailed probing system, similar to "-cpu ?dump", but in a more extensible and machine-friendly format.

Current design proposal

• -query-capabilities RFC series from Anthony
  • Message-Id: <1332169763-30665-9-git-send-email-aliguori@us.ibm.com>
• To be defined: Command to list CPU models, and the features they include/exclude
• To be defined: Command to list the resulting CPUID bits of CPU models
  • Do we need a version that works before the VM is created? Some bits depend on other Virtual Machine parameters (e.g. SMP configuration), so it won't list every single bit
  • Do we need a version that works after the VM is created, so it lists every single bit? (maybe just the "query-cpus" QMP command is already enough for that)
    • Probably the final solution will require libvirt to actually create a VM and run a "query-cpus" (or similar) command to get the resulting CPUID bits
• To be defined: command to query which CPU flags are really available and can be enabled (based on host hardware + kernel + qemu capabilities)

-cpu host and feature probing

See http://article.gmane.org/gmane.comp.emulators.kvm.devel/90035

-cpu host vs -cpu best

Currently we have -cpu host, but the naming and semantics are unclear.

We have 3 possible modes of "try to get the best CPU model":

1. all-you-can-enable: Enable every single bit that can be enabled, including the ones not present on the host but that can be emulated.
2. match-host-CPU: Enable all bits that are present in the host CPU that can be enabled.
3. best-predefined-model: Use the best CPU model available from the pre-defined CPU model list.

Proposal

• -cpu host will be the "all-you-can-enable" mode, that will enable every bit from GET_SUPPORTED_CPUID on the VCPU
• The best-predefined-model will be implemented using -cpu best.

It's unclear if we're going to have an option for match-host-CPU (probably not).