rpms/qemu-kvm
7
0
Fork 0
Code Issues Pull Requests Releases Activity

* Tue Jan 07 2020 Danilo Cesar Lemes de Paula <ddepaula@redhat.com> - 4.2.0-5.el8

Browse Source 
- kvm-i386-Remove-cpu64-rhel6-CPU-model.patch [bz#1741345]
- kvm-Reallocate-dirty_bmap-when-we-change-a-slot.patch [bz#1772774]
- Resolves: bz#1741345
  (Remove the "cpu64-rhel6" CPU from qemu-kvm)
- Resolves: bz#1772774
  (qemu-kvm core dump during migration+reboot ( Assertion `mem->dirty_bmap' failed ))
This commit is contained in:
Danilo C. L. de Paula 2020-01-07 20:29:46 +00:00
parent 1261d6ce5b
commit 1390e099ea
3 changed files with 205 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

115
kvm-Reallocate-dirty_bmap-when-we-change-a-slot.patch Normal file
View File

@ -0,0 +1,115 @@
From c477581ccc6962651d4d6c702a6c3e2fcc5e4205 Mon Sep 17 00:00:00 2001
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Date: Thu, 2 Jan 2020 11:56:51 +0000
Subject: [PATCH 2/2] kvm: Reallocate dirty_bmap when we change a slot
RH-Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-id: <20200102115651.140177-1-dgilbert@redhat.com>
Patchwork-id: 93256
O-Subject: [RHEL-AV-8.2.0 qemu-kvm PATCH 1/1] kvm: Reallocate dirty_bmap when we change a slot
Bugzilla: 1772774
RH-Acked-by: Peter Xu <peterx@redhat.com>
RH-Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
RH-Acked-by: Laszlo Ersek <lersek@redhat.com>
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
bz: https://bugzilla.redhat.com/show_bug.cgi?id=1772774
brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=25575691
branch: rhel-av-8.2.0
kvm_set_phys_mem can be called to reallocate a slot by something the
guest does (e.g. writing to PAM and other chipset registers).
This can happen in the middle of a migration, and if we're unlucky
it can now happen between the split 'sync' and 'clear'; the clear
asserts if there's no bmap to clear. Recreate the bmap whenever
we change the slot, keeping the clear path happy.
Typically this is triggered by the guest rebooting during a migrate.
Corresponds to:
https://bugzilla.redhat.com/show_bug.cgi?id=1772774
https://bugzilla.redhat.com/show_bug.cgi?id=1771032
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit 9b3a31c745b61758aaa5466a3a9fc0526d409188)
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
---
accel/kvm/kvm-all.c | 44 +++++++++++++++++++++++++++++---------------
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index dc3ed7f..5007bda 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -518,6 +518,27 @@ static int kvm_get_dirty_pages_log_range(MemoryRegionSection *section,
#define ALIGN(x, y) (((x)+(y)-1) & ~((y)-1))
+/* Allocate the dirty bitmap for a slot */
+static void kvm_memslot_init_dirty_bitmap(KVMSlot *mem)
+{
+ /*
+ * XXX bad kernel interface alert
+ * For dirty bitmap, kernel allocates array of size aligned to
+ * bits-per-long. But for case when the kernel is 64bits and
+ * the userspace is 32bits, userspace can't align to the same
+ * bits-per-long, since sizeof(long) is different between kernel
+ * and user space. This way, userspace will provide buffer which
+ * may be 4 bytes less than the kernel will use, resulting in
+ * userspace memory corruption (which is not detectable by valgrind
+ * too, in most cases).
+ * So for now, let's align to 64 instead of HOST_LONG_BITS here, in
+ * a hope that sizeof(long) won't become >8 any time soon.
+ */
+ hwaddr bitmap_size = ALIGN(((mem->memory_size) >> TARGET_PAGE_BITS),
+ /*HOST_LONG_BITS*/ 64) / 8;
+ mem->dirty_bmap = g_malloc0(bitmap_size);
+}
+
/**
* kvm_physical_sync_dirty_bitmap - Sync dirty bitmap from kernel space
*
@@ -550,23 +571,9 @@ static int kvm_physical_sync_dirty_bitmap(KVMMemoryListener *kml,
goto out;
}
- /* XXX bad kernel interface alert
- * For dirty bitmap, kernel allocates array of size aligned to
- * bits-per-long. But for case when the kernel is 64bits and
- * the userspace is 32bits, userspace can't align to the same
- * bits-per-long, since sizeof(long) is different between kernel
- * and user space. This way, userspace will provide buffer which
- * may be 4 bytes less than the kernel will use, resulting in
- * userspace memory corruption (which is not detectable by valgrind
- * too, in most cases).
- * So for now, let's align to 64 instead of HOST_LONG_BITS here, in
- * a hope that sizeof(long) won't become >8 any time soon.
- */
if (!mem->dirty_bmap) {
- hwaddr bitmap_size = ALIGN(((mem->memory_size) >> TARGET_PAGE_BITS),
- /*HOST_LONG_BITS*/ 64) / 8;
/* Allocate on the first log_sync, once and for all */
- mem->dirty_bmap = g_malloc0(bitmap_size);
+ kvm_memslot_init_dirty_bitmap(mem);
}
d.dirty_bitmap = mem->dirty_bmap;
@@ -1067,6 +1074,13 @@ static void kvm_set_phys_mem(KVMMemoryListener *kml,
mem->ram = ram;
mem->flags = kvm_mem_flags(mr);
+ if (mem->flags & KVM_MEM_LOG_DIRTY_PAGES) {
+ /*
+ * Reallocate the bmap; it means it doesn't disappear in
+ * middle of a migrate.
+ */
+ kvm_memslot_init_dirty_bitmap(mem);
+ }
err = kvm_set_user_memory_region(kml, mem, true);
if (err) {
fprintf(stderr, "%s: error registering slot: %s\n", __func__,
--
1.8.3.1

77
kvm-i386-Remove-cpu64-rhel6-CPU-model.patch Normal file
View File

@ -0,0 +1,77 @@
From 4543a3c19816bd07f27eb900f20ae609df03703c Mon Sep 17 00:00:00 2001
From: Eduardo Habkost <ehabkost@redhat.com>
Date: Mon, 23 Dec 2019 21:10:31 +0000
Subject: [PATCH 1/2] i386: Remove cpu64-rhel6 CPU model
RH-Author: Eduardo Habkost <ehabkost@redhat.com>
Message-id: <20191223211031.26503-1-ehabkost@redhat.com>
Patchwork-id: 93213
O-Subject: [RHEL-AV-8.2.0 qemu-kvm PATCH] i386: Remove cpu64-rhel6 CPU model
Bugzilla: 1741345
RH-Acked-by: Daniel P. Berrange <berrange@redhat.com>
RH-Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
RH-Acked-by: Laszlo Ersek <lersek@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1741345
BRANCH: rhel-av-8.2.0
Upstream: not applicable
Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=25525975
We don't provide rhel6 machine types anymore, so we don't need to
provide compatibility with RHEl6. cpu64-rhel6 was documented as
deprecated and scheduled for removal in 8.2, so now it's time to
remove it.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
---
target/i386/cpu.c | 26 +-------------------------
1 file changed, 1 insertion(+), 25 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 790db77..6dce6f2 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1829,12 +1829,7 @@ static CPUCaches epyc_cache_info = {
static X86CPUDefinition builtin_x86_defs[] = {
{
- /* qemu64 is the default CPU model for all *-rhel7.* machine-types.
- * The default on RHEL-6 was cpu64-rhel6.
- * libvirt assumes that qemu64 is the default for _all_ machine-types,
- * so we should try to keep qemu64 and cpu64-rhel6 as similar as
- * possible.
- */
+ /* qemu64 is the default CPU model for all machine-types */
.name = "qemu64",
.level = 0xd,
.vendor = CPUID_VENDOR_AMD,
@@ -2135,25 +2130,6 @@ static X86CPUDefinition builtin_x86_defs[] = {
.model_id = "Intel(R) Atom(TM) CPU N270 @ 1.60GHz",
},
{
- .name = "cpu64-rhel6",
- .level = 4,
- .vendor = CPUID_VENDOR_AMD,
- .family = 6,
- .model = 13,
- .stepping = 3,
- .features[FEAT_1_EDX] = CPUID_SSE2 | CPUID_SSE | CPUID_FXSR |
- CPUID_MMX | CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV |
- CPUID_MCA | CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC |
- CPUID_CX8 | CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC |
- CPUID_PSE | CPUID_DE | CPUID_FP87,
- .features[FEAT_1_ECX] = CPUID_EXT_CX16 | CPUID_EXT_SSE3,
- .features[FEAT_8000_0001_EDX] = CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
- .features[FEAT_8000_0001_ECX] = CPUID_EXT3_SSE4A | CPUID_EXT3_ABM |
- CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
- .xlevel = 0x8000000A,
- .model_id = "QEMU Virtual CPU version (cpu64-rhel6)",
- },
- {
.name = "Conroe",
.level = 10,
.vendor = CPUID_VENDOR_INTEL,
--
1.8.3.1

14
qemu-kvm.spec
View File

@ -67,7 +67,7 @@ Obsoletes: %1-rhev
Summary: QEMU is a machine emulator and virtualizer
Name: qemu-kvm
Version: 4.2.0
Release: 4%{?dist}
Release: 5%{?dist}
# Epoch because we pushed a qemu-1.0 package. AIUI this can't ever be dropped
Epoch: 15
License: GPLv2 and GPLv2+ and CC-BY
@ -121,6 +121,10 @@ Patch0018: 0018-usb-xhci-Fix-PCI-capability-order.patch
Patch0019: 0019-virtio-scsi-Reject-scsi-cd-if-data-plane-enabled-RHE.patch
Patch0020: 0020-BZ1653590-Require-at-least-64kiB-pages-for-downstrea.patch
Patch0021: 0021-Using-ip_deq-after-m_free-might-read-pointers-from-a.patch
# For bz#1741345 - Remove the "cpu64-rhel6" CPU from qemu-kvm
Patch22: kvm-i386-Remove-cpu64-rhel6-CPU-model.patch
# For bz#1772774 - qemu-kvm core dump during migration+reboot ( Assertion `mem->dirty_bmap' failed )
Patch23: kvm-Reallocate-dirty_bmap-when-we-change-a-slot.patch
BuildRequires: wget
BuildRequires: rpm-build
@ -1055,6 +1059,14 @@ useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin \
%changelog
* Tue Jan 07 2020 Danilo Cesar Lemes de Paula <ddepaula@redhat.com> - 4.2.0-5.el8
- kvm-i386-Remove-cpu64-rhel6-CPU-model.patch [bz#1741345]
- kvm-Reallocate-dirty_bmap-when-we-change-a-slot.patch [bz#1772774]
- Resolves: bz#1741345
(Remove the "cpu64-rhel6" CPU from qemu-kvm)
- Resolves: bz#1772774
(qemu-kvm core dump during migration+reboot ( Assertion `mem->dirty_bmap' failed ))
* Fri Dec 13 2019 Danilo Cesar Lemes de Paula <ddepaula@redhat.com> - 4.2.0-4.el8
- Rebase to qemu-4.2
- Resolves: bz#1783250