From patchwork Wed Feb 19 11:46:06 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kashyap Chamarthy X-Patchwork-Id: 1240663 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=VqCJN3KJ; dkim-atps=neutral Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 48Mwwk3KY4z9sRh for ; Wed, 19 Feb 2020 22:48:54 +1100 (AEDT) Received: from localhost ([::1]:51302 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4NqW-000838-D8 for incoming@patchwork.ozlabs.org; Wed, 19 Feb 2020 06:48:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47546) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4NoC-0006KD-2g for qemu-devel@nongnu.org; Wed, 19 Feb 2020 06:46:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4No6-0004Wx-Hb for qemu-devel@nongnu.org; Wed, 19 Feb 2020 06:46:28 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:52792 helo=us-smtp-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j4No6-0004Wh-Aw for qemu-devel@nongnu.org; Wed, 19 Feb 2020 06:46:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582112782; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wssEO4Hem1W7CwIFIprztXMqfs3EnbMw0pRjIdMM0jo=; b=VqCJN3KJT7IjkV/O7uJ2GVLGQctW/P7wAFJy/S0Bfzuorsap0LWnHrwhInQlv9Y2upapFM 8K8kGyDlb7Prs/HihlvlpXKgqooKqVjwO0lqQI4n7t54ZKj9NGyl8ekeJeBsqjUsMPwOHd m/wOoX/IS2Fg3spvgOPufMabZ3CFPds= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-283-V6M1VPh1PlG-Cri7bx9Qag-1; Wed, 19 Feb 2020 06:46:13 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ACFF0800D4E; Wed, 19 Feb 2020 11:46:12 +0000 (UTC) Received: from paraplu.localdomain (unknown [10.36.118.84]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2681319E9C; Wed, 19 Feb 2020 11:46:10 +0000 (UTC) From: Kashyap Chamarthy To: kchamart@redhat.com, qemu-devel@nongnu.org Subject: [PATCH v2 1/2] docs: Convert qemu-cpu-models.texi to rST Date: Wed, 19 Feb 2020 12:46:06 +0100 Message-Id: <20200219114607.1855-2-kchamart@redhat.com> In-Reply-To: <20200219114607.1855-1-kchamart@redhat.com> References: <20200219114607.1855-1-kchamart@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: V6M1VPh1PlG-Cri7bx9Qag-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 207.211.31.120 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: peter.maydell@linaro.org, berrange@redhat.com, ehabkost@redhat.com Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" This doc was originally written by Daniel P. Berrangé , introduced via commit[1]: 2544e9e4aa (docs: add guidance on configuring CPU models for x86, 2018-06-27). This is a 1-1 conversion of Texinfo to rST, besides a couple of minor non-content tweaks that are too trivial to spell out. Further modifications will be done via a separate patch. (Thanks to Stephen Finucane on IRC for the suggestion to use rST "definition lists" instead of bullets in some places.) [1] https://git.qemu.org/?p=qemu.git;a=commit;h=2544e9e4aa Signed-off-by: Kashyap Chamarthy --- docs/qemu-cpu-models.texi | 677 -------------------------------- docs/system/index.rst | 1 + docs/system/qemu-cpu-models.rst | 496 +++++++++++++++++++++++ 3 files changed, 497 insertions(+), 677 deletions(-) delete mode 100644 docs/qemu-cpu-models.texi create mode 100644 docs/system/qemu-cpu-models.rst diff --git a/docs/qemu-cpu-models.texi b/docs/qemu-cpu-models.texi deleted file mode 100644 index f88a1def0d..0000000000 --- a/docs/qemu-cpu-models.texi +++ /dev/null @@ -1,677 +0,0 @@ -@c man begin SYNOPSIS -QEMU / KVM CPU model configuration -@c man end - -@set qemu_system_x86 qemu-system-x86_64 - -@c man begin DESCRIPTION - -@menu -* recommendations_cpu_models_x86:: Recommendations for KVM CPU model configuration on x86 hosts -* recommendations_cpu_models_MIPS:: Supported CPU model configurations on MIPS hosts -* cpu_model_syntax_apps:: Syntax for configuring CPU models -@end menu - -QEMU / KVM virtualization supports two ways to configure CPU models - -@table @option - -@item 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. - -@item 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. - -@node recommendations_cpu_models_x86 -@subsection 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. - -@menu -* preferred_cpu_models_intel_x86:: Preferred CPU models for Intel x86 hosts -* important_cpu_features_intel_x86:: Important CPU features for Intel x86 hosts -* preferred_cpu_models_amd_x86:: Preferred CPU models for AMD x86 hosts -* important_cpu_features_amd_x86:: Important CPU features for AMD x86 hosts -* default_cpu_models_x86:: Default x86 CPU models -* other_non_recommended_cpu_models_x86:: Other non-recommended x86 CPUs -@end menu - -@node preferred_cpu_models_intel_x86 -@subsubsection Preferred CPU models for Intel x86 hosts - -The following CPU models are preferred for use on Intel hosts. Administrators / -applications are recommended to use the CPU model that matches the generation -of the host CPUs in use. 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. - -@table @option -@item @code{Skylake-Server} -@item @code{Skylake-Server-IBRS} - -Intel Xeon Processor (Skylake, 2016) - - -@item @code{Skylake-Client} -@item @code{Skylake-Client-IBRS} - -Intel Core Processor (Skylake, 2015) - - -@item @code{Broadwell} -@item @code{Broadwell-IBRS} -@item @code{Broadwell-noTSX} -@item @code{Broadwell-noTSX-IBRS} - -Intel Core Processor (Broadwell, 2014) - - -@item @code{Haswell} -@item @code{Haswell-IBRS} -@item @code{Haswell-noTSX} -@item @code{Haswell-noTSX-IBRS} - -Intel Core Processor (Haswell, 2013) - - -@item @code{IvyBridge} -@item @code{IvyBridge-IBRS} - -Intel Xeon E3-12xx v2 (Ivy Bridge, 2012) - - -@item @code{SandyBridge} -@item @code{SandyBridge-IBRS} - -Intel Xeon E312xx (Sandy Bridge, 2011) - - -@item @code{Westmere} -@item @code{Westmere-IBRS} - -Westmere E56xx/L56xx/X56xx (Nehalem-C, 2010) - - -@item @code{Nehalem} -@item @code{Nehalem-IBRS} - -Intel Core i7 9xx (Nehalem Class Core i7, 2008) - - -@item @code{Penryn} - -Intel Core 2 Duo P9xxx (Penryn Class Core 2, 2007) - - -@item @code{Conroe} - -Intel Celeron_4x0 (Conroe/Merom Class Core 2, 2006) - -@end table - -@node important_cpu_features_intel_x86 -@subsubsection Important CPU features for Intel x86 hosts - -The following are important CPU features that should be used on Intel x86 -hosts, when available in the host CPU. Some of them require explicit -configuration to enable, as they are not included by default in some, or all, -of the named CPU models listed above. In general all of these features are -included if using "Host passthrough" or "Host model". - - -@table @option - -@item @code{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. - - -@item @code{spec-ctrl} - -Required to enable the Spectre v2 (CVE-2017-5715) fix. - -Included by default in Intel CPU models with -IBRS suffix. - -Must be explicitly turned on for Intel CPU models without -IBRS suffix. - -Requires the host CPU microcode to support this feature before it -can be used for guest CPUs. - - -@item @code{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. - - -@item @code{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. - - -@item @code{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. - -@item @code{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. -@end table - - -@node preferred_cpu_models_amd_x86 -@subsubsection Preferred CPU models for AMD x86 hosts - -The following CPU models are preferred for use on Intel hosts. Administrators / -applications are recommended to use the CPU model that matches the generation -of the host CPUs in use. 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. - -@table @option - -@item @code{EPYC} -@item @code{EPYC-IBPB} - -AMD EPYC Processor (2017) - - -@item @code{Opteron_G5} - -AMD Opteron 63xx class CPU (2012) - - -@item @code{Opteron_G4} - -AMD Opteron 62xx class CPU (2011) - - -@item @code{Opteron_G3} - -AMD Opteron 23xx (Gen 3 Class Opteron, 2009) - - -@item @code{Opteron_G2} - -AMD Opteron 22xx (Gen 2 Class Opteron, 2006) - - -@item @code{Opteron_G1} - -AMD Opteron 240 (Gen 1 Class Opteron, 2004) -@end table - -@node important_cpu_features_amd_x86 -@subsubsection Important CPU features for AMD x86 hosts - -The following are important CPU features that should be used on AMD x86 -hosts, when available in the host CPU. Some of them require explicit -configuration to enable, as they are not included by default in some, or all, -of the named CPU models listed above. In general all of these features are -included if using "Host passthrough" or "Host model". - - -@table @option - -@item @code{ibpb} - -Required to enable the Spectre v2 (CVE-2017-5715) fix. - -Included by default in AMD CPU models with -IBPB suffix. - -Must be explicitly turned on for AMD CPU models without -IBPB suffix. - -Requires the host CPU microcode to support this feature before it -can be used for guest CPUs. - - -@item @code{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. - - -@item @code{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 when using "Host model", because this is a virtual feature -that doesn't exist in the physical host CPUs. - - -@item @code{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. - - -@item @code{amd-no-ssb} - -Recommended to indicate the host is not vulnerable 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. - - -@item @code{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. -@end table - - -@node default_cpu_models_x86 -@subsubsection 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 do perform any host compatibility checks -before launching guests, the default is guaranteed to work. - -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 setup a better CPU configuration, with host -passthrough recommended if live migration is not needed. - -@table @option -@item @code{qemu32} -@item @code{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 is provided in libvirt XML. -@end table - - -@node other_non_recommended_cpu_models_x86 -@subsubsection 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. - -@table @option - -@item @code{kvm32} -@item @code{kvm64} - -Common KVM processor (32 & 64 bit variants) - -Legacy models just for historical compatibility with ancient QEMU versions. - - -@item @code{486} -@item @code{athlon} -@item @code{phenom} -@item @code{coreduo} -@item @code{core2duo} -@item @code{n270} -@item @code{pentium} -@item @code{pentium2} -@item @code{pentium3} - -Various very old x86 CPU models, mostly predating the introduction of -hardware assisted virtualization, that should thus not be required for -running virtual machines. -@end table - -@node recommendations_cpu_models_MIPS -@subsection Supported CPU model configurations on MIPS hosts - -QEMU supports variety of MIPS CPU models: - -@menu -* cpu_models_MIPS32:: Supported CPU models for MIPS32 hosts -* cpu_models_MIPS64:: Supported CPU models for MIPS64 hosts -* cpu_models_nanoMIPS:: Supported CPU models for nanoMIPS hosts -* preferred_cpu_models_MIPS:: Preferred CPU models for MIPS hosts -@end menu - -@node cpu_models_MIPS32 -@subsubsection Supported CPU models for MIPS32 hosts - -The following CPU models are supported for use on MIPS32 hosts. Administrators / -applications are recommended to use the CPU model that matches the generation -of the host CPUs in use. 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. - -@table @option -@item @code{mips32r6-generic} - -MIPS32 Processor (Release 6, 2015) - - -@item @code{P5600} - -MIPS32 Processor (P5600, 2014) - - -@item @code{M14K} -@item @code{M14Kc} - -MIPS32 Processor (M14K, 2009) - - -@item @code{74Kf} - -MIPS32 Processor (74K, 2007) - - -@item @code{34Kf} - -MIPS32 Processor (34K, 2006) - - -@item @code{24Kc} -@item @code{24KEc} -@item @code{24Kf} - -MIPS32 Processor (24K, 2003) - - -@item @code{4Kc} -@item @code{4Km} -@item @code{4KEcR1} -@item @code{4KEmR1} -@item @code{4KEc} -@item @code{4KEm} - -MIPS32 Processor (4K, 1999) -@end table - -@node cpu_models_MIPS64 -@subsubsection Supported CPU models for MIPS64 hosts - -The following CPU models are supported for use on MIPS64 hosts. Administrators / -applications are recommended to use the CPU model that matches the generation -of the host CPUs in use. 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. - -@table @option -@item @code{I6400} - -MIPS64 Processor (Release 6, 2014) - - -@item @code{Loongson-2F} - -MIPS64 Processor (Loongson 2, 2008) - - -@item @code{Loongson-2E} - -MIPS64 Processor (Loongson 2, 2006) - - -@item @code{mips64dspr2} - -MIPS64 Processor (Release 2, 2006) - - -@item @code{MIPS64R2-generic} -@item @code{5KEc} -@item @code{5KEf} - -MIPS64 Processor (Release 2, 2002) - - -@item @code{20Kc} - -MIPS64 Processor (20K, 2000) - - -@item @code{5Kc} -@item @code{5Kf} - -MIPS64 Processor (5K, 1999) - - -@item @code{VR5432} - -MIPS64 Processor (VR, 1998) - - -@item @code{R4000} - -MIPS64 Processor (MIPS III, 1991) -@end table - -@node cpu_models_nanoMIPS -@subsubsection Supported CPU models for nanoMIPS hosts - -The following CPU models are supported for use on nanoMIPS hosts. Administrators / -applications are recommended to use the CPU model that matches the generation -of the host CPUs in use. 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. - -@table @option -@item @code{I7200} - -MIPS I7200 (nanoMIPS, 2018) - -@end table - -@node preferred_cpu_models_MIPS -@subsubsection Preferred CPU models for MIPS hosts - -The following CPU models are preferred for use on different MIPS hosts: - -@table @option -@item @code{MIPS III} -R4000 - -@item @code{MIPS32R2} -34Kf - -@item @code{MIPS64R6} -I6400 - -@item @code{nanoMIPS} -I7200 -@end table - -@node cpu_model_syntax_apps -@subsection Syntax for configuring CPU models - -The example below illustrate the approach to configuring the various -CPU models / features in QEMU and libvirt - -@menu -* cpu_model_syntax_qemu:: QEMU command line -* cpu_model_syntax_libvirt:: Libvirt guest XML -@end menu - -@node cpu_model_syntax_qemu -@subsubsection QEMU command line - -@table @option - -@item Host passthrough - -@example - $ @value{qemu_system_x86} -cpu host -@end example - -With feature customization: - -@example - $ @value{qemu_system_x86} -cpu host,-vmx,... -@end example - -@item Named CPU models - -@example - $ @value{qemu_system_x86} -cpu Westmere -@end example - -With feature customization: - -@example - $ @value{qemu_system_x86} -cpu Westmere,+pcid,... -@end example - -@end table - -@node cpu_model_syntax_libvirt -@subsubsection Libvirt guest XML - -@table @option - -@item Host passthrough - -@example - -@end example - -With feature customization: - -@example - - - ... - -@end example - -@item Host model - -@example - -@end example - -With feature customization: - -@example - - - ... - -@end example - -@item Named model - -@example - - - -@end example - -With feature customization: - -@example - - - - ... - -@end example - -@end table - -@c man end - -@ignore - -@setfilename qemu-cpu-models -@settitle QEMU / KVM CPU model configuration - -@c man begin SEEALSO -The HTML documentation of QEMU for more precise information and Linux -user mode emulator invocation. -@c man end - -@c man begin AUTHOR -Daniel P. Berrange -@c man end - -@end ignore diff --git a/docs/system/index.rst b/docs/system/index.rst index f66e6ea585..849dcd8cb8 100644 --- a/docs/system/index.rst +++ b/docs/system/index.rst @@ -15,3 +15,4 @@ Contents: :maxdepth: 2 qemu-block-drivers + qemu-cpu-models diff --git a/docs/system/qemu-cpu-models.rst b/docs/system/qemu-cpu-models.rst new file mode 100644 index 0000000000..2332fba1f9 --- /dev/null +++ b/docs/system/qemu-cpu-models.rst @@ -0,0 +1,496 @@ +QEMU / KVM CPU model configuration +================================== + +QEMU / KVM virtualization supports two ways to configure CPU models: + +(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. + + +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. + + +Preferred CPU models for Intel x86 hosts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following CPU models are preferred for use on Intel hosts. +Administrators / applications are recommended to use the CPU model that +matches the generation of the host CPUs in use. 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. + +* Intel Xeon Processor (Skylake, 2016) + + * ``Skylake-Server`` + * ``Skylake-Server-IBRS`` + +* Intel Core Processor (Skylake, 2015) + + * ``Skylake-Client`` + * ``Skylake-Client-IBRS`` + +* Intel Core Processor (Broadwell, 2014) + + * ``Broadwell`` + * ``Broadwell-IBRS`` + * ``Broadwell-noTSX`` + * ``Broadwell-noTSX-IBRS`` + +* Intel Core Processor (Haswell, 2013) + + * ``Haswell`` + * ``Haswell-IBRS`` + * ``Haswell-noTSX`` + * ``Haswell-noTSX-IBRS`` + +* Intel Xeon E3-12xx v2 (Ivy Bridge, 2012) + + * ``IvyBridge`` + * ``IvyBridge-IBR`` + +* Intel Xeon E312xx (Sandy Bridge, 2011) + + * ``SandyBridge`` + * ``SandyBridge-IBRS`` + +* Westmere E56xx/L56xx/X56xx (Nehalem-C, 2010) + + * ``Westmere`` + * ``Westmere-IBRS`` + +* Intel Core i7 9xx (Nehalem Class Core i7, 2008) + + * ``Nehalem`` + * ``Nehalem-IBRS`` + +* Intel Core 2 Duo P9xxx (Penryn Class Core 2, 2007) + + * ``Penryn`` + +* Intel Celeron_4x0 (Conroe/Merom Class Core 2, 2006) + + * ``Conroe`` + + +Important CPU features for Intel x86 hosts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following are important CPU features that should be used on Intel +x86 hosts, when available in the host CPU. Some of them require explicit +configuration to enable, as they are not included by default in some, or +all, of the named CPU models listed above. In general all of these +features are included if using "Host passthrough" or "Host model". + +``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. + +``spec-ctrl`` + Required to enable the Spectre v2 (CVE-2017-5715) fix. + + Included by default in Intel CPU models with -IBRS suffix. + + Must be explicitly turned on for Intel CPU models without -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. + +``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. + + +Preferred CPU models for AMD x86 hosts +-------------------------------------- + +The following CPU models are preferred for use on Intel hosts. +Administrators / applications are recommended to use the CPU model that +matches the generation of the host CPUs in use. 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. + +* AMD EPYC Processor (2017) + + * ``EPYC`` + * ``EPYC-IBPB`` + +* ``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 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following are important CPU features that should be used on AMD x86 +hosts, when available in the host CPU. Some of them require explicit +configuration to enable, as they are not included by default in some, or +all, of the named CPU models listed above. In general all of these +features are included if 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 -IBPB suffix. + + Must be explicitly turned on for AMD CPU models without -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 + when using "Host model", because this is a virtual feature that + doesn't exist in the physical host CPUs. + +``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``. + +``amd-no-ssb`` + Recommended to indicate the host is not vulnerable 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. + +``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. + + +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 do perform any host +compatibility checks before launching guests, the default is guaranteed +to work. + +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 setup a better CPU +configuration, with host passthrough recommended if live migration is +not needed. + +* QEMU Virtual CPU version 2.5+ (32 & 64 bit variants) + + * ``qemu32`` + * ``qemu64`` + + ``qemu64`` is used for x86_64 guests and ``qemu32`` is used for i686 + guests, when no ``-cpu`` argument is given to QEMU, or no ```` 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. + +* Common KVM processor (32 & 64 bit variants): + + * ``kvm32`` + * ``kvm64`` + + Legacy models just for historical compatibility with ancient QEMU + versions. + +* Various very old x86 CPU models, mostly predating the introduction of + hardware assisted virtualization, that should thus not be required for + running virtual machines. + + * ``486`` + * ``athlon`` + * ``phenom`` + * ``coreduo`` + * ``core2duo`` + * ``n270`` + * ``pentium`` + * ``pentium2`` + * ``pentium3`` + + +Supported CPU model configurations on MIPS hosts +------------------------------------------------ + +QEMU supports variety of MIPS CPU models: + +Supported CPU models for MIPS32 hosts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following CPU models are supported for use on MIPS32 hosts. +Administrators / applications are recommended to use the CPU model that +matches the generation of the host CPUs in use. 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. + +* ``mips32r6-generic`` -- MIPS32 Processor (Release 6, 2015) + +* ``P5600`` -- MIPS32 Processor (P5600, 2014) + +* MIPS32 Processor (M14K, 2009) + + * ``M14K`` + * ``M14Kc`` + +* ``74Kf`` -- MIPS32 Processor (74K, 2007) + +* ``34Kf`` -- MIPS32 Processor (34K, 2006) + +* MIPS32 Processor (24K, 2003) + + * ``24Kc`` + * ``24KEc`` + * ``24Kf`` + +* MIPS32 Processor (4K, 1999) + + * ``4Kc`` + * ``4Km`` + * ``4KEcR1`` + * ``4KEmR1`` + * ``4KEc`` + * ``4KEm`` + + +Supported CPU models for MIPS64 hosts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following CPU models are supported for use on MIPS64 hosts. +Administrators / applications are recommended to use the CPU model that +matches the generation of the host CPUs in use. 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. + +* ``I6400`` -- MIPS64 Processor (Release 6, 2014) + +* ``Loongson-2F`` -- MIPS64 Processor (Loongson 2, 2008) + +* ``Loongson-2E`` -- MIPS64 Processor (Loongson 2, 2006) + +* ``mips64dspr2`` -- MIPS64 Processor (Release 2, 2006) + +* MIPS64 Processor (Release 2, 2002) + + * ``MIPS64R2-generic`` + * ``5KEc`` + * ``5KEf`` + +* ``20Kc`` -- MIPS64 Processor (20K, 2000 + +* MIPS64 Processor (5K, 1999) + + * ``5Kc`` + * ``5Kf`` + +* ``VR5432`` -- MIPS64 Processor (VR, 1998) + +* ``R4000`` -- MIPS64 Processor (MIPS III, 1991) + + +Supported CPU models for nanoMIPS hosts +--------------------------------------- + +The following CPU models are supported for use on nanoMIPS hosts. +Administrators / applications are recommended to use the CPU model that +matches the generation of the host CPUs in use. 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. + +* ``I7200`` -- MIPS I7200 (nanoMIPS, 2018) + +Preferred CPU models for MIPS hosts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following CPU models are preferred for use on different MIPS hosts: + +* ``MIPS III`` -- R4000 + +* ``MIPS32R2`` -- 34Kf + +* ``MIPS64R6`` -- I6400 + +* ``nanoMIPS`` -- I7200 + +Syntax for configuring CPU models +--------------------------------- + +The example below illustrate the approach to configuring the various +CPU models / features in QEMU and libvirt + +QEMU command line +~~~~~~~~~~~~~~~~~ + +Host passthrough:: + + $ qemu_system_x86 -cpu host + +Host passthrough with feature customization:: + + $ qemu_system_x86 -cpu host,-vmx,... + +Named CPU models:: + + $ qemu_system_x86 -cpu Westmere + +Named CPU models with feature customization:: + + $ qemu_system_x86 -cpu Westmere,+pcid,... + +Libvirt guest XML +~~~~~~~~~~~~~~~~~ + +Host passthrough:: + + + +Host passthrough with feature customization:: + + + + ... + + +Host model:: + + + +Host model with feature customization:: + + + + ... + + +Named model:: + + + + + +Named model with feature customization:: + + + + + ... + From patchwork Wed Feb 19 11:46:07 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kashyap Chamarthy X-Patchwork-Id: 1240662 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=eTtTFkcU; dkim-atps=neutral Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 48Mwtl0Q9sz9sRh for ; Wed, 19 Feb 2020 22:47:09 +1100 (AEDT) Received: from localhost ([::1]:51290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4Nop-0006LZ-PX for incoming@patchwork.ozlabs.org; Wed, 19 Feb 2020 06:47:07 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47531) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4NoA-0006Hh-3W for qemu-devel@nongnu.org; Wed, 19 Feb 2020 06:46:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4No8-0004Xc-AZ for qemu-devel@nongnu.org; Wed, 19 Feb 2020 06:46:26 -0500 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:45724 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j4No8-0004XB-6Y for qemu-devel@nongnu.org; Wed, 19 Feb 2020 06:46:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582112783; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GMHTra8XgW0Lfzs5jPKH7c0H1FtCNmxKAFmw26cbOVE=; b=eTtTFkcUZhNuuurpkKxsD0V4dkJaCgiKs5PnbfIe1nlrTtM6TaOHlDzjmlB+b8zMuurYEJ sFijK12LlbFEfgkt8IpLyLdB1tUts1qRI2caKw3o12bsHOHUa0w5J0vQHGYPc9VR89Uixk iozeuSvre549kBRvoArFHBySRfKWp0E= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-158-WcdFAUNaOKqF1uodmu8N7w-1; Wed, 19 Feb 2020 06:46:15 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 419D2800D50; Wed, 19 Feb 2020 11:46:14 +0000 (UTC) Received: from paraplu.localdomain (unknown [10.36.118.84]) by smtp.corp.redhat.com (Postfix) with ESMTP id F369D19E9C; Wed, 19 Feb 2020 11:46:12 +0000 (UTC) From: Kashyap Chamarthy To: kchamart@redhat.com, qemu-devel@nongnu.org Subject: [PATCH v2 2/2] qemu-cpu-models.rst: Document -noTSX, mds-no, taa-no, and tsx-ctrl Date: Wed, 19 Feb 2020 12:46:07 +0100 Message-Id: <20200219114607.1855-3-kchamart@redhat.com> In-Reply-To: <20200219114607.1855-1-kchamart@redhat.com> References: <20200219114607.1855-1-kchamart@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: WcdFAUNaOKqF1uodmu8N7w-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 205.139.110.61 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: peter.maydell@linaro.org, berrange@redhat.com, ehabkost@redhat.com Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" - Add the '-noTSX' variants for CascadeLake and SkyLake. - Document the three MSR bits: 'mds-no', 'taa-no', and 'tsx-ctrl' Two confusing things about 'mds-no' (and the first point applies to the other two MSRs too): (1) The 'mds-no' bit will _not_ show up in the guest's /proc/cpuinfo. Rather it is used to fill in the guest's sysfs: /sys/devices/system/cpu/vulnerabilities/mds:Not affected Paolo confirmed on IRC as such. (2) There are _three_ variants[+] of CascadeLake CPUs, with different stepping levels: 5, 6, and 7. To quote wikichip.org[*]: "note that while steppings 6 & 7 are fully mitigated, earlier stepping 5 is not protected against MSBDS, MLPDS, nor MDSUM" The above is also indicated in the Intel's document[+], as indicated by "No" under the three columns of MFBDS, MSBDS, and MLPDS. I've expressed this in the docs without belabouring the details. [+] https://software.intel.com/security-software-guidance/insights/processors-affected-microarchitectural-data-sampling [*] https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#Key_changes_from_Skylake Signed-off-by: Kashyap Chamarthy --- [Retaining the change-log from the Texinfo-variant of this patch, which is now no-longer needed: https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg06455.html] v3: - Address feedback from Paolo - Add URL to the deep-dive on Intel's MDS v2: - Address feedback from DanPB - Add sections on 'taa-no' and 'tsx-ctrl' Signed-off-by: Kashyap Chamarthy --- docs/system/qemu-cpu-models.rst | 61 ++++++++++++++++++++++++++++++--- 1 file changed, 56 insertions(+), 5 deletions(-) diff --git a/docs/system/qemu-cpu-models.rst b/docs/system/qemu-cpu-models.rst index 2332fba1f9..5030dbef64 100644 --- a/docs/system/qemu-cpu-models.rst +++ b/docs/system/qemu-cpu-models.rst @@ -51,15 +51,18 @@ 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. +* Intel Xeon Processor (Cascade Lake, 2019), with "stepping" levels 6 or + 7 only. (The Cascade Lake Xeon processor with *stepping 5 is + vulnerable to MDS variants*.) + + * ``Cascadelake-Server`` + * ``Cascadelake-Server-noTSX`` + * Intel Xeon Processor (Skylake, 2016) * ``Skylake-Server`` * ``Skylake-Server-IBRS`` - -* Intel Core Processor (Skylake, 2015) - - * ``Skylake-Client`` - * ``Skylake-Client-IBRS`` + * ``Skylake-Server-IBRS-noTSX`` * Intel Core Processor (Broadwell, 2014) @@ -172,6 +175,54 @@ features are included if using "Host passthrough" or "Host model". 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, + so 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. + +``taa-no`` + Recommended to inform that the guest that the host is ``not`` + vulnerable to CVE-2019-11135, TSX Asynchronous Abort (TAA). + + This too is an MSR feature, so 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 this + `Intel's deep-dive into + MDS `_.) + + 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. + + By disabling TSX, KVM-based guests can avoid paying the price of + mitigting TSX-based attacks. + + Note that ``tsx-ctrl`` too is an MSR feature, so 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``. + Preferred CPU models for AMD x86 hosts --------------------------------------