Recommendations for KVM CPU model configuration on x86 hosts

The information that follows provides recommendations for configuring CPU models on x86 hosts. The goals are to maximise performance, while protecting guest OS against various CPU hardware flaws, and optionally enabling live migration between hosts with heterogeneous CPU models.

Two ways to configure CPU models with QEMU / KVM

1. Host passthrough

   This passes the host CPU model features, model, stepping, exactly to the guest. Note that KVM may filter out some host CPU model features if they cannot be supported with virtualization. Live migration is unsafe when this mode is used as libvirt / QEMU cannot guarantee a stable CPU is exposed to the guest across hosts. This is the recommended CPU to use, provided live migration is not required.

2. Named model

   QEMU comes with a number of predefined named CPU models, that typically refer to specific generations of hardware released by Intel and AMD. These allow the guest VMs to have a degree of isolation from the host CPU, allowing greater flexibility in live migrating between hosts with differing hardware. @end table

In both cases, it is possible to optionally add or remove individual CPU features, to alter what is presented to the guest by default.

Libvirt supports a third way to configure CPU models known as “Host model”. This uses the QEMU “Named model” feature, automatically picking a CPU model that is similar the host CPU, and then adding extra features to approximate the host model as closely as possible. This does not guarantee the CPU family, stepping, etc will precisely match the host CPU, as they would with “Host passthrough”, but gives much of the benefit of passthrough, while making live migration safe.

ABI compatibility levels for CPU models

The x86_64 architecture has a number of ABI compatibility levels defined. Traditionally most operating systems and toolchains would only target the original baseline ABI. It is expected that in future OS and toolchains are likely to target newer ABIs. The table that follows illustrates which ABI compatibility levels can be satisfied by the QEMU CPU models. Note that the table only lists the long term stable CPU model versions (eg Haswell-v4). In addition to what is listed, there are also many CPU model aliases which resolve to a different CPU model version, depending on the machine type is in use.

x86-64 ABI compatibility levels

Model	baseline	v2	v3	v4
486-v1
Broadwell-v1	✅	✅	✅
Broadwell-v2	✅	✅	✅
Broadwell-v3	✅	✅	✅
Broadwell-v4	✅	✅	✅
Cascadelake-Server-v1	✅	✅	✅	✅
Cascadelake-Server-v2	✅	✅	✅	✅
Cascadelake-Server-v3	✅	✅	✅	✅
Cascadelake-Server-v4	✅	✅	✅	✅
Conroe-v1	✅
Cooperlake-v1	✅	✅	✅	✅
Denverton-v1	✅	✅
Denverton-v2	✅	✅
Dhyana-v1	✅	✅	✅
EPYC-Milan-v1	✅	✅	✅
EPYC-Rome-v1	✅	✅	✅
EPYC-Rome-v2	✅	✅	✅
EPYC-v1	✅	✅	✅
EPYC-v2	✅	✅	✅
EPYC-v3	✅	✅	✅
Haswell-v1	✅	✅	✅
Haswell-v2	✅	✅	✅
Haswell-v3	✅	✅	✅
Haswell-v4	✅	✅	✅
Icelake-Client-v1	✅	✅	✅
Icelake-Client-v2	✅	✅	✅
Icelake-Server-v1	✅	✅	✅	✅
Icelake-Server-v2	✅	✅	✅	✅
Icelake-Server-v3	✅	✅	✅	✅
Icelake-Server-v4	✅	✅	✅	✅
IvyBridge-v1	✅	✅
IvyBridge-v2	✅	✅
KnightsMill-v1	✅	✅	✅
Nehalem-v1	✅	✅
Nehalem-v2	✅	✅
Opteron_G1-v1	✅
Opteron_G2-v1	✅
Opteron_G3-v1	✅
Opteron_G4-v1	✅	✅
Opteron_G5-v1	✅	✅