qemu-kvm/kvm-i386-Resolve-CPU-models-to-v1-by-default.patch
Danilo C. L. de Paula fda7fbcd8d * Fri Feb 14 2020 Danilo Cesar Lemes de Paula <ddepaula@redhat.com> - 4.2.0-10.el8
- kvm-i386-Resolve-CPU-models-to-v1-by-default.patch [bz#1779078 bz#1787291 bz#1779078 bz#1779078]
- kvm-iotests-Support-job-complete-in-run_job.patch [bz#1781637]
- kvm-iotests-Create-VM.blockdev_create.patch [bz#1781637]
- kvm-block-Activate-recursively-even-for-already-active-n.patch [bz#1781637]
- kvm-hmp-Allow-using-qdev-ID-for-qemu-io-command.patch [bz#1781637]
- kvm-iotests-Test-external-snapshot-with-VM-state.patch [bz#1781637]
- kvm-iotests.py-Let-wait_migration-wait-even-more.patch [bz#1781637]
- kvm-blockdev-fix-coding-style-issues-in-drive_backup_pre.patch [bz#1745606 bz#1746217 bz#1773517 bz#1779036 bz#1782111 bz#1782175 bz#1783965]
- kvm-blockdev-unify-qmp_drive_backup-and-drive-backup-tra.patch [bz#1745606 bz#1746217 bz#1773517 bz#1779036 bz#1782111 bz#1782175 bz#1783965]
- kvm-blockdev-unify-qmp_blockdev_backup-and-blockdev-back.patch [bz#1745606 bz#1746217 bz#1773517 bz#1779036 bz#1782111 bz#1782175 bz#1783965]
- kvm-blockdev-honor-bdrv_try_set_aio_context-context-requ.patch [bz#1745606 bz#1746217 bz#1773517 bz#1779036 bz#1782111 bz#1782175 bz#1783965]
- kvm-backup-top-Begin-drain-earlier.patch [bz#1745606 bz#1746217 bz#1773517 bz#1779036 bz#1782111 bz#1782175 bz#1783965]
- kvm-block-backup-top-Don-t-acquire-context-while-droppin.patch [bz#1745606 bz#1746217 bz#1773517 bz#1779036 bz#1782111 bz#1782175 bz#1783965]
- kvm-blockdev-Acquire-AioContext-on-dirty-bitmap-function.patch [bz#1745606 bz#1746217 bz#1773517 bz#1779036 bz#1782111 bz#1782175 bz#1783965]
- kvm-blockdev-Return-bs-to-the-proper-context-on-snapshot.patch [bz#1745606 bz#1746217 bz#1773517 bz#1779036 bz#1782111 bz#1782175 bz#1783965]
- kvm-iotests-Test-handling-of-AioContexts-with-some-block.patch [bz#1745606 bz#1746217 bz#1773517 bz#1779036 bz#1782111 bz#1782175 bz#1783965]
- kvm-target-arm-monitor-query-cpu-model-expansion-crashed.patch [bz#1801320]
- kvm-docs-arm-cpu-features-Make-kvm-no-adjvtime-comment-c.patch [bz#1801320]
- Resolves: bz#1745606
  (Qemu hang when do incremental live backup in transaction mode without bitmap)
- Resolves: bz#1746217
  (Src qemu hang when do storage vm migration during guest installation)
- Resolves: bz#1773517
  (Src qemu hang when do storage vm migration with dataplane enable)
- Resolves: bz#1779036
  (Qemu coredump when do snapshot in transaction mode with one snapshot path not exist)
- Resolves: bz#1779078
  (RHVH 4.4: Failed to run VM on 4.3/4.4 engine (Exit message: the CPU is incompatible with host CPU: Host CPU does not provide required features: hle, rtm))
- Resolves: bz#1781637
  (qemu crashed when do mem and disk snapshot)
- Resolves: bz#1782111
  (Qemu hang when do full backup on multi-disks with one job's 'job-id' missed in transaction mode(data plane enable))
- Resolves: bz#1782175
  (Qemu core dump when add persistent bitmap(data plane enable))
- Resolves: bz#1783965
  (Qemu core dump when do backup with sync: bitmap and no bitmap provided)
- Resolves: bz#1787291
  (RHVH 4.4: Failed to run VM on 4.3/4.4 engine (Exit message: the CPU is incompatible with host CPU: Host CPU does not provide required features: hle, rtm) [rhel-8.1.0.z])
- Resolves: bz#1801320
  (aarch64: backport query-cpu-model-expansion and adjvtime document fixes)
2020-02-14 03:03:11 +00:00

96 lines
3.9 KiB
Diff

From ccda4494b0ea4b81b6b0c3e539a0bcf7e673c68c Mon Sep 17 00:00:00 2001
From: Eduardo Habkost <ehabkost@redhat.com>
Date: Thu, 5 Dec 2019 21:56:50 +0000
Subject: [PATCH 01/18] i386: Resolve CPU models to v1 by default
RH-Author: Eduardo Habkost <ehabkost@redhat.com>
Message-id: <20191205225650.772600-2-ehabkost@redhat.com>
Patchwork-id: 92907
O-Subject: [RHEL-AV-8.1.1 qemu-kvm PATCH 1/1] i386: Resolve CPU models to v1 by default
Bugzilla: 1787291 1779078 1779078
RH-Acked-by: Danilo de Paula <ddepaula@redhat.com>
RH-Acked-by: Igor Mammedov <imammedo@redhat.com>
RH-Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779078
Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=25187823
Upstream: submitted, Message-Id: <20191205223339.764534-1-ehabkost@redhat.com>
When using `query-cpu-definitions` using `-machine none`,
QEMU is resolving all CPU models to their latest versions. The
actual CPU model version being used by another machine type (e.g.
`pc-q35-4.0`) might be different.
In theory, this was OK because the correct CPU model
version is returned when using the correct `-machine` argument.
Except that in practice, this breaks libvirt expectations:
libvirt always use `-machine none` when checking if a CPU model
is runnable, because runnability is not expected to be affected
when the machine type is changed.
For example, when running on a Haswell host without TSX,
Haswell-v4 is runnable, but Haswell-v1 is not. On those hosts,
`query-cpu-definitions` says Haswell is runnable if using
`-machine none`, but Haswell is actually not runnable using any
of the `pc-*` machine types (because they resolve Haswell to
Haswell-v1). In other words, we're breaking the "runnability
guarantee" we promised to not break for a few releases (see
qemu-deprecated.texi).
To address this issue, change the default CPU model version to v1
on all machine types, so we make `query-cpu-definitions` output
when using `-machine none` match the results when using `pc-*`.
This will change in the future (the plan is to always return the
latest CPU model version if using `-machine none`), but only
after giving libvirt the opportunity to adapt.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1779078
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
---
qemu-deprecated.texi | 7 +++++++
target/i386/cpu.c | 8 +++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 4b4b742..534ebe9 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -374,6 +374,13 @@ guarantees must resolve the CPU model aliases using te
``alias-of'' field returned by the ``query-cpu-definitions'' QMP
command.
+While those guarantees are kept, the return value of
+``query-cpu-definitions'' will have existing CPU model aliases
+point to a version that doesn't break runnability guarantees
+(specifically, version 1 of those CPU models). In future QEMU
+versions, aliases will point to newer CPU model versions
+depending on the machine type, so management software must
+resolve CPU model aliases before starting a virtual machine.
@node Recently removed features
@appendix Recently removed features
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 6dce6f2..863192c 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3926,7 +3926,13 @@ static PropValue tcg_default_props[] = {
};
-X86CPUVersion default_cpu_version = CPU_VERSION_LATEST;
+/*
+ * We resolve CPU model aliases using -v1 when using "-machine
+ * none", but this is just for compatibility while libvirt isn't
+ * adapted to resolve CPU model versions before creating VMs.
+ * See "Runnability guarantee of CPU models" at * qemu-deprecated.texi.
+ */
+X86CPUVersion default_cpu_version = 1;
void x86_cpu_set_default_version(X86CPUVersion version)
{
--
1.8.3.1