QEMU-CPU-MODELS(7)

💅 qemu-cpu-models — the manual page, but make it a group chat

okay so bestie, welcome to the QEMU CPU Modelling Infrastructure manual ✨ — yes, that's the whole synopsis, we're keeping it exactly like that, and the official page name is qemu-cpu-models. Let's get into it 🎀

---

🌸 DESCRIPTION 🌸

✨ Recommendations for KVM CPU model configuration on x86 hosts ✨

So like, everything below is the tea on how to configure CPU models on x86 hosts. The goals are iconic and threefold: maximise performance, protect the guest OS against various CPU hardware flaws, and — optionally — enable live migration between hosts with heterogeneous CPU models. That's the whole vibe check. 🦋

💖 Two ways to configure CPU models with QEMU / KVM 💖

1. 🌈 Host passthrough

This one passes the host CPU model features, model, and stepping exactly to the guest. No filter, no nothing, straight through. 💅

🫶 but heads up: KVM may filter out some host CPU model features if they cannot be supported with virtualization. Also, live migration is unsafe when this mode is used, because libvirt / QEMU cannot guarantee a stable CPU is exposed to the guest across hosts. The way that syntax has no chill 😭

That said — this is the recommended CPU to use, provided live migration is not required. Slay. 👑

2. 🎀 Named model

QEMU comes with a number of predefined named CPU models, which typically refer to specific generations of hardware released by Intel and AMD. This lets guest VMs have a degree of isolation from the host CPU, which lowkey gives you greater flexibility in live migrating between hosts with differing hardware. That's the whole reason it exists, periodt. ⭐

@end table

💀 yes bestie, that @end table is literally just sitting there in the original, I don't make the rules, I just deliver the facts 🍓

---

In both cases, it is possible to optionally add or remove individual CPU features, to alter what is presented to the guest by default. Customization? We love her. 💜

---

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 to the host CPU, and then adding extra features to approximate the host model as closely as possible. 🧚

🙈 real talk: this does not guarantee the CPU family, stepping, etc will precisely match the host CPU, as they would with "Host passthrough". But it gives much of the benefit of passthrough while making live migration safe — we call that a compromise that ate. 🔥

⭐ ABI compatibility levels for CPU models ⭐

The x86_64 architecture has a number of ABI compatibility levels defined — that definition lives over at https://gitlab.com/x86-psABIs/x86-64-ABI/ if you wanna go look. 🌈

Traditionally, most operating systems and toolchains would only target the original baseline ABI. But 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. iykyk 😌

---

more parts incoming bestie, don't go anywhere 💖✨

✨ x86-64 ABI compatibility levels ✨

Okay bestie, so this next bit is basically the vibe check for all the x86-64 models — like, which ABI levels each one is actually compatible with. The four columns in the OG table were baseline, v2, v3 and v4, and a ✅ meant "yes queen, compatible." So I'm gonna list each model with the levels it eats for breakfast. If a level is missing from the list, it's a no. 💅

• 486-v1 — compatible with none of baseline, v2, v3, v4. She's doing her own thing, honestly. 💀
• Broadwell-v1 — baseline ✅, v2 ✅, v3 ✅
• Broadwell-v2 — baseline ✅, v2 ✅, v3 ✅
• Broadwell-v3 — baseline ✅, v2 ✅, v3 ✅
• Broadwell-v4 — baseline ✅, v2 ✅, v3 ✅
• Cascadelake-Server-v1 — baseline ✅, v2 ✅, v3 ✅, v4 ✅ — full house, icon behaviour 👑
• Cascadelake-Server-v2 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Cascadelake-Server-v3 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Cascadelake-Server-v4 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Cascadelake-Server-v5 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Conroe-v1 — baseline ✅ only. minimal queen, we respect her 🎀
• Cooperlake-v1 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Cooperlake-v2 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Denverton-v1 — baseline ✅, v2 ✅
• Denverton-v2 — baseline ✅, v2 ✅
• Denverton-v3 — baseline ✅, v2 ✅
• Dhyana-v1 — baseline ✅, v2 ✅, v3 ✅
• Dhyana-v2 — baseline ✅, v2 ✅, v3 ✅
• EPYC-Genoa-v1 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• EPYC-Milan-v1 — baseline ✅, v2 ✅, v3 ✅
• EPYC-Milan-v2 — baseline ✅, v2 ✅, v3 ✅
• EPYC-Rome-v1 — baseline ✅, v2 ✅, v3 ✅
• EPYC-Rome-v2 — baseline ✅, v2 ✅, v3 ✅
• EPYC-Rome-v3 — baseline ✅, v2 ✅, v3 ✅
• EPYC-Rome-v4 — baseline ✅, v2 ✅, v3 ✅
• EPYC-v1 — baseline ✅, v2 ✅, v3 ✅
• EPYC-v2 — baseline ✅, v2 ✅, v3 ✅
• EPYC-v3 — baseline ✅, v2 ✅, v3 ✅
• EPYC-v4 — baseline ✅, v2 ✅, v3 ✅
• GraniteRapids-v1 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Haswell-v1 — baseline ✅, v2 ✅, v3 ✅
• Haswell-v2 — baseline ✅, v2 ✅, v3 ✅
• Haswell-v3 — baseline ✅, v2 ✅, v3 ✅
• Haswell-v4 — baseline ✅, v2 ✅, v3 ✅
• Icelake-Server-v1 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Icelake-Server-v2 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Icelake-Server-v3 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Icelake-Server-v4 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Icelake-Server-v5 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• Icelake-Server-v6 — baseline ✅, v2 ✅, v3 ✅, v4 ✅
• IvyBridge-v1 — baseline ✅, v2 ✅
• IvyBridge-v2 — baseline ✅, v2 ✅
• KnightsMill-v1 — baseline ✅, v2 ✅, v3 ✅
• Nehalem-v1 — baseline ✅, v2 ✅
• Nehalem-v2 — baseline ✅, v2 ✅

...and we're back in the table, bestie 💅 same four feature columns as before, just read straight across:

• Opteron_G1-v1 — col 1 ✅
• Opteron_G2-v1 — col 1 ✅
• Opteron_G3-v1 — col 1 ✅
• Opteron_G4-v1 — col 1 ✅, col 2 ✅
• Opteron_G5-v1 — col 1 ✅, col 2 ✅
• Penryn-v1 — col 1 ✅
• SandyBridge-v1 — col 1 ✅, col 2 ✅
• SandyBridge-v2 — col 1 ✅, col 2 ✅
• SapphireRapids-v1 — col 1 ✅, col 2 ✅, col 3 ✅, col 4 ✅
• SapphireRapids-v2 — col 1 ✅, col 2 ✅, col 3 ✅, col 4 ✅
• Skylake-Client-v1 — col 1 ✅, col 2 ✅, col 3 ✅
• Skylake-Client-v2 — col 1 ✅, col 2 ✅, col 3 ✅
• Skylake-Client-v3 — col 1 ✅, col 2 ✅, col 3 ✅
• Skylake-Client-v4 — col 1 ✅, col 2 ✅, col 3 ✅
• Skylake-Server-v1 — col 1 ✅, col 2 ✅, col 3 ✅, col 4 ✅
• Skylake-Server-v2 — col 1 ✅, col 2 ✅, col 3 ✅, col 4 ✅
• Skylake-Server-v3 — col 1 ✅, col 2 ✅, col 3 ✅, col 4 ✅
• Skylake-Server-v4 — col 1 ✅, col 2 ✅, col 3 ✅, col 4 ✅
• Skylake-Server-v5 — col 1 ✅, col 2 ✅, col 3 ✅, col 4 ✅
• Snowridge-v1 — col 1 ✅, col 2 ✅
• Snowridge-v2 — col 1 ✅, col 2 ✅
• Snowridge-v3 — col 1 ✅, col 2 ✅
• Snowridge-v4 — col 1 ✅, col 2 ✅
• Westmere-v1 — col 1 ✅, col 2 ✅
• Westmere-v2 — col 1 ✅, col 2 ✅
• athlon-v1 — nothing checked, my condolences 🫶
• core2duo-v1 — col 1 ✅
• coreduo-v1 — nothing checked
• kvm32-v1 — nothing checked
• kvm64-v1 — col 1 ✅
• n270-v1 — nothing checked
• pentium-v1 — nothing checked
• pentium2-v1 — nothing checked
• pentium3-v1 — nothing checked
• phenom-v1 — col 1 ✅
• qemu32-v1 — nothing checked
• qemu64-v1 — col 1 ✅

---

✨ Preferred CPU models for Intel x86 hosts ✨

ok so if you're sitting on Intel hardware, these are the ✨it girls✨ of CPU models. The guidance is honestly so simple: admins and apps should pick the CPU model that matches the generation of the host CPUs you're actually running. 💖

And if you're living that messy deployment life with a mixture of host CPU models across machines? If live migration compatibility matters to you (and honestly it usually does 😭), then use the newest CPU model that is compatible across all the desired hosts — the intersection of the vibes, basically. 🔥

---

🌈 DiamondRapids

Intel Xeon Processor (DiamondRapids, 2026)

Big fun fact: this one does not include SMT, but it does give you the module (dual core module – DCM) and die (core building block – CBB) topology levels. The cache hierarchy is L1 i/d cache per thread, L2 cache per module, and L3 cache per die — and you can emulate all of that with the smp-cache option, like so:

-machine smp-cache.0.cache=l1d,smp-cache.0.topology=thread,\
         smp-cache.1.cache=l1i,smp-cache.1.topology=thread,\
         smp-cache.2.cache=l2,smp-cache.2.topology=module,\
         smp-cache.3.cache=l3,smp-cache.3.topology=die

🦋 ClearwaterForest

Intel Xeon Processor (ClearwaterForest, 2025)

🌸 SierraForest, SierraForest-v2

Intel Xeon Processor (SierraForest, 2024), and SierraForest-v2 mitigates the GDS and RFDS vulnerabilities with stepping 3. (mitigation queen 👑)

🎀 GraniteRapids, GraniteRapids-v2

Intel Xeon Processor (GraniteRapids, 2024)

💜 Cascadelake-Server, Cascadelake-Server-noTSX

Intel Xeon Processor (Cascade Lake, 2019), with stepping levels 6 or 7 only.

Heads up bestie — the Cascade Lake Xeon processor with stepping 5 is vulnerable to MDS variants. Not it. 💀

⭐ Skylake-Server, Skylake-Server-IBRS, Skylake-Server-IBRS-noTSX

Intel Xeon Processor (Skylake, 2016)

🧚 Skylake-Client, Skylake-Client-IBRS, Skylake-Client-noTSX-IBRS}

Intel Core Processor (Skylake, 2015)

(yes there's a stray } in there fr fr — I kept it, character for character, don't come for me 🙈)

🍓 Broadwell, Broadwell-IBRS, Broadwell-noTSX, Broadwell-noTSX-IBRS

Intel Core Processor (Broadwell, 2014)

💖 Haswell, Haswell-IBRS, Haswell-noTSX, Haswell-noTSX-IBRS

Intel Core Processor (Haswell, 2013)

🌺 IvyBridge, IvyBridge-IBR

Intel Xeon E3-12xx v2 (Ivy Bridge, 2012)

🌟 SandyBridge, SandyBridge-IBRS

Intel Xeon E312xx (Sandy Bridge, 2011)

💫 Westmere, Westmere-IBRS

Westmere E56xx/L56xx/X56xx (Nehalem-C, 2010)

• Nehalem, Nehalem-IBRS — Intel Core i7 9xx (Nehalem Class Core i7, 2008) 💜
• Penryn — Intel Core 2 Duo P9xxx (Penryn Class Core 2, 2007) ✨
• Conroe — Intel Celeron_4x0 (Conroe/Merom Class Core 2, 2006) 🌸

💖 Important CPU features for Intel x86 hosts

okay bestie this is the glow-up section 💅 these are the important CPU features you should be using on Intel x86 hosts whenever your host CPU actually has them. Some of them need you to explicitly turn them on, because they're not included by default in some — or literally all — of the named CPU models listed above. As a general rule tho? All of these are already in there if you're using Host passthrough or Host model. slay.

pcid

Recommended to mitigate the cost of the Meltdown (CVE-2017-5754) fix. 🔥

Included by default in Haswell, Broadwell & Skylake Intel CPU models.

Should be explicitly turned on for Westmere, SandyBridge, and IvyBridge Intel CPU models. Note that some desktop/mobile Westmere CPUs cannot support this feature — like, they just can't, no cap 😭.

spec-ctrl

Required to enable the Spectre v2 (CVE-2017-5715) fix.

Included by default in Intel CPU models with the -IBRS suffix.

Must be explicitly turned on for Intel CPU models without the -IBRS suffix.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

stibp

Required to enable stronger Spectre v2 (CVE-2017-5715) fixes in some operating systems.

Must be explicitly turned on for all Intel CPU models.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

ssbd

Required to enable the CVE-2018-3639 fix.

Not included by default in any Intel CPU model.

Must be explicitly turned on for all Intel CPU models.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

pdpe1gb

Recommended to allow guest OS to use 1GB size pages 👑

Not included by default in any Intel CPU model.

Should be explicitly turned on for all Intel CPU models.

Note that not all CPU hardware will support this feature. check before you commit, bestie 🙈

md-clear

Required to confirm the MDS (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091) fixes.

Not included by default in any Intel CPU model.

Must be explicitly turned on for all Intel CPU models.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

mds-no

Recommended to inform the guest OS that the host is not vulnerable to any of the MDS variants ([MFBDS] CVE-2018-12130, [MLPDS] CVE-2018-12127, [MSBDS] CVE-2018-12126).

This is an MSR (Model-Specific Register) feature rather than a CPUID feature, therefore it will not appear in the Linux /proc/cpuinfo in the host or guest. Instead, the host kernel uses it to populate the MDS vulnerability file in sysfs.

So it should only be enabled for VMs if the host reports @code{Not affected} in the /sys/devices/system/cpu/vulnerabilities/mds file. iykyk 🧚

taa-no

Recommended to inform the guest that the host is not vulnerable to CVE-2019-11135, TSX Asynchronous Abort (TAA).

This is also an MSR feature, therefore it does not show up in the Linux /proc/cpuinfo in the host or guest.

It should only be enabled for VMs if the host reports Not affected in the /sys/devices/system/cpu/vulnerabilities/tsx_async_abort file.

tsx-ctrl

Recommended to inform the guest that it can disable the Intel TSX (Transactional Synchronization Extensions) feature; or, if the processor is vulnerable, use the Intel VERW instruction (a processor-level instruction that performs checks on memory access) as a mitigation for the TAA vulnerability. (For details, refer to Intel's deep dive into MDS <https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling>.) 🔍

Expose this to the guest OS if and only if: (a) the host has TSX enabled; and (b) the guest has rtm CPU flag enabled. both conditions, bestie, not one or the other 👀

By disabling TSX, KVM-based guests can avoid paying the price of mitigating TSX-based attacks. we love a cost-saving queen 💸

Note that tsx-ctrl is also an MSR feature, therefore it does not show up in the Linux /proc/cpuinfo in the host or guest.

To validate that Intel TSX is indeed disabled for the guest, there are two ways: (a) check for the absence of rtm in the guest's /proc/cpuinfo; or (b) the /sys/devices/system/cpu/vulnerabilities/tsx_async_abort file in the guest should report Mitigation: TSX disabled.

bhi-no

Recommended to inform the guest that the host is not vulnerable to CVE-2022-0001, Branch History Injection (BHI).

This is also an MSR feature, therefore it does not show up in the Linux /proc/cpuinfo in the host or guest.

It should only be enabled for VMs if the host reports BHI: Not affected in the /sys/devices/system/cpu/vulnerabilities/spectre_v2 file.

gds-no

Recommended to inform the guest that the host is not vulnerable to CVE-2022-40982, Gather Data Sampling (GDS).

This is also an MSR feature, therefore it does not show up in the Linux /proc/cpuinfo in the host or guest.

It should only be enabled for VMs if the host reports Not affected in the /sys/devices/system/cpu/vulnerabilities/gather_data_sampling file.

rfds-no

Recommended to inform the guest that the host is not vulnerable to CVE-2023-28746, Register File Data Sampling (RFDS).

This is also an MSR feature, therefore it does not show up in the Linux /proc/cpuinfo in the host or guest.

It should only be enabled for VMs if the host reports Not affected in the /sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling file.

---

🦋 Preferred CPU models for AMD x86 hosts

The following CPU models are preferred for use on AMD hosts. Admins / applications, listen up: use the CPU model that matches the generation of the host CPUs you're actually using, fr fr. In a deployment with a mixture of host CPU models between machines, if live migration compatibility is required, use the newest CPU model that is compatible across all desired hosts. main character energy only ✨

• EPYC, EPYC-IBPB — AMD EPYC Processor (2017) 👑
• Opteron_G5 — AMD Opteron 63xx class CPU (2012)
• Opteron_G4 — AMD Opteron 62xx class CPU (2011)
• Opteron_G3 — AMD Opteron 23xx (Gen 3 Class Opteron, 2009)
• Opteron_G2 — AMD Opteron 22xx (Gen 2 Class Opteron, 2006)
• Opteron_G1 — AMD Opteron 240 (Gen 1 Class Opteron, 2004)

💀 Important CPU features for AMD x86 hosts

Same deal, AMD edition 🫶 these are the important CPU features that should be used on AMD x86 hosts when your host CPU has them. Some need explicit configuration to enable, since they're not included by default in some — or all — of the named CPU models listed above. Generally all of these are included if you're using Host passthrough or Host model.

ibpb

Required to enable the Spectre v2 (CVE-2017-5715) fix.

Included by default in AMD CPU models with the -IBPB suffix.

Must be explicitly turned on for AMD CPU models without the -IBPB suffix.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

stibp

Required to enable stronger Spectre v2 (CVE-2017-5715) fixes in some operating systems.

Must be explicitly turned on for all AMD CPU models.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

virt-ssbd

Required to enable the CVE-2018-3639 fix

Not included by default in any AMD CPU model.

Must be explicitly turned on for all AMD CPU models.

This should be provided to guests, even if amd-ssbd is also provided, for maximum guest compatibility.

Note: for some QEMU / libvirt versions, this must be force enabled when using Host model, because this is a virtual feature that doesn't exist in the physical host CPUs. like, it's fictional bestie, you gotta hand-deliver it 💅

amd-ssbd

Required to enable the CVE-2018-3639 fix

Not included by default in any AMD CPU model.

Must be explicitly turned on for all AMD CPU models.

This provides higher performance than virt-ssbd so should be exposed to guests whenever available in the host. virt-ssbd should none the less also be exposed for maximum guest compatibility as some kernels only know about virt-ssbd. both. do both. slay 🎀

amd-no-ssb

Recommended to indicate the host is not vulnerable to CVE-2018-3639

Not included by default in any AMD CPU model.

Future hardware generations of CPU will not be vulnerable to CVE-2018-3639, and thus the guest should be told not to enable its mitigations, by exposing amd-no-ssb. This is mutually exclusive with virt-ssbd and amd-ssbd. pick a lane 😭

pdpe1gb

Recommended to allow guest OS to use 1GB size pages

Not included by default in any AMD CPU model.

Should be explicitly turned on for all AMD CPU models.

Note that not all CPU hardware will support this feature. same warning, different day 🙈

---

🌈 Default x86 CPU models

The default QEMU CPU models are designed such that they can run on all hosts. If an application does not wish to perform any host compatibility checks before launching guests, the default is guaranteed to work. it's giving "safe boring little guy" energy ngl ⭐

The default CPU models will, however, leave the guest OS vulnerable to various CPU hardware flaws, so their use is strongly discouraged. Applications should follow the earlier guidance to set up a better CPU configuration, with host passthrough recommended if live migration is not needed. like, this is the "we're not mad, we're just disappointed" of CPU models 💀

• qemu32, qemu64 — QEMU Virtual CPU version 2.5+ (32 & 64 bit variants)

qemu64 is used for x86_64 guests and qemu32 is used for i686 guests, when no -cpu argument is given to QEMU, or no <cpu> is provided in libvirt XML.

🍓 Other non-recommended x86 CPUs

The following CPUs models are compatible with most AMD and Intel x86 hosts, but their usage is discouraged, as they expose a very limited featureset, which prevents guests having optimal performance. iconic in a "historical artifact" way, not in a "use this" way 🧚

• kvm32, kvm64 — Common KVM processor (32 & 64 bit variants).

Legacy models just for historical compatibility with ancient QEMU versions.

• 486, athlon, phenom, coreduo, core2duo, n270, pentium, pentium2, pentium3 — the ✨vintage✨ x86 lineup: a whole squad of very old CPU models, most of them older than hardware-assisted virtualization even existed. So yeah, you should not need any of these to run a virtual machine. They're giving museum exhibit, not main character. 💀

---

🛠️ Syntax for configuring CPU models

Okay bestie, the examples below show you how to configure all these CPU models and features in QEMU and libvirt. Same idea, two flavours. 🍓

💻 QEMU command line

Host passthrough — just hand over the whole host CPU, no notes:

qemu-system-x86_64 -cpu host

Host passthrough but you're micromanaging the features:

qemu-system-x86_64 -cpu host,vmx=off,...

Named CPU models — you pick a specific one off the menu:

qemu-system-x86_64 -cpu Westmere

Named CPU model with feature customization — the model plus your little tweaks:

qemu-system-x86_64 -cpu Westmere,pcid=on,...

🧚 Libvirt guest XML

Host passthrough:

<cpu mode='host-passthrough'/>

Host passthrough with feature customization:

<cpu mode='host-passthrough'>
    <feature name="vmx" policy="disable"/>
    ...
</cpu>

Host model:

<cpu mode='host-model'/>

Host model with feature customization:

<cpu mode='host-model'>
    <feature name="vmx" policy="disable"/>
    ...
</cpu>

Named model:

<cpu mode='custom'>
    <model name="Westmere"/>
</cpu>

Named model with feature customization:

<cpu mode='custom'>
    <model name="Westmere"/>
    <feature name="pcid" policy="require"/>
    ...
</cpu>

---

🌈 Supported CPU model configurations on MIPS hosts

QEMU supports a whole variety of MIPS CPU models, and honestly? She contains multitudes. 🦋

🎀 Supported CPU models for MIPS32 hosts

These are the CPU models supported for use on MIPS32 hosts. Administrators and applications should lowkey use the CPU model that matches the generation of the host CPUs you're actually running. And if your deployment has a mixture of host CPU models across machines, and you need live migration compatibility, then use the newest CPU model that's compatible across all the desired hosts. The way that's just the rule. 💅

• mips32r6-generic — MIPS32 Processor (Release 6, 2015)
• P5600 — MIPS32 Processor (P5600, 2014)
• M14K, M14Kc — MIPS32 Processor (M14K, 2009)
• 74Kf — MIPS32 Processor (74K, 2007)
• 34Kf — MIPS32 Processor (34K, 2006)
• 24Kc, 24KEc, 24Kf — MIPS32 Processor (24K, 2003)
• 4Kc, 4Km, 4KEcR1, 4KEmR1, 4KEc, 4KEm — MIPS32 Processor (4K, 1999)

⭐ Supported CPU models for MIPS64 hosts

And these are the CPU models supported for use on MIPS64 hosts. Same advice, fr fr: admins and applications should use the CPU model matching the generation of the host CPUs in use. Got a mix of host CPU models between machines and need live migration compatibility? Use the newest CPU model that's compatible across all desired hosts. Iconic behaviour only. 👑

• I6400 — MIPS64 Processor (Release 6, 2014)
• Loongson-2E — MIPS64 Processor (Loongson 2, 2006)
• Loongson-2F — MIPS64 Processor (Loongson 2, 2008)
• Loongson-3A1000 — MIPS64 Processor (Loongson 3, 2010)
• Loongson-3A4000 — MIPS64 Processor (Loongson 3, 2018)
• mips64dspr2 — MIPS64 Processor (Release 2, 2006)
• MIPS64R2-generic, 5KEc, 5KEf — MIPS64 Processor (Release 2, 2002)
• 20Kc — MIPS64 Processor (20K, 2000
• 5Kc, 5Kf — MIPS64 Processor (5K, 1999)
• VR5432 — MIPS64 Processor (VR, 1998)
• R4000 — MIPS64 Processor (MIPS III, 1991)

🙈 Not me pointing out that 20Kc's line really does end without its closing paren — (20K, 2000 — that's exactly how it ships, so I'm leaving it untouched. Copy it verbatim, bestie.

🦋 Supported CPU models for nanoMIPS hosts

Now for the nanoMIPS girlies. These are the CPU models supported for use on nanoMIPS hosts. Administrators and applications are recommended to use the CPU model that matches the generation of the host CPUs in use, and if you've got a mixture of host CPU models between machines plus a need for live migration compatibility, use the newest CPU model that's compatible across all desired hosts. Same energy, different architecture. ✨

• I7200 — MIPS I7200 (nanoMIPS, 2018)

👑 Preferred CPU models for MIPS hosts

These are the CPU models preferred for use on the different MIPS hosts — like a little cheat sheet, iykyk:

• MIPS III — R4000
• MIPS32R2 — 34Kf
• MIPS64R6 — I6400
• nanoMIPS — I7200

---

🔍 SEE ALSO

The HTML documentation of QEMU for more precise information, plus Linux user mode emulator invocation. Go read it, it ate. 💖

🫶 Author

The QEMU Project developers

📜 Copyright

2026, The QEMU Project Developers

---

That's the whole page, bestie — you made it to the end and you absolutely slayed it. 🌸

Signing off with all the love: this was QEMU-CPU-MODELS(7), version 11.1.3, dated Oct 29, 2026. Periodt. 💅🎀