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

* Wed Jan 15 2020 Danilo Cesar Lemes de Paula <ddepaula@redhat.com> - 4.2.0-6.el8

Browse Source 
- kvm-spapr-Don-t-trigger-a-CAS-reboot-for-XICS-XIVE-mode-.patch [bz#1733893]
- kvm-vfio-pci-Don-t-remove-irqchip-notifier-if-not-regist.patch [bz#1782678]
- kvm-virtio-don-t-enable-notifications-during-polling.patch [bz#1789301]
- kvm-usbredir-Prevent-recursion-in-usbredir_write.patch [bz#1790844]
- kvm-xhci-recheck-slot-status.patch [bz#1790844]
- Resolves: bz#1733893
  (Boot a guest with "-prom-env 'auto-boot?=false'", SLOF failed to enter the boot entry after input "boot" followed by "0 > " on VNC)
- Resolves: bz#1782678
  (qemu core dump after hot-unplugging the   XXV710/XL710 PF)
- Resolves: bz#1789301
  (virtio-blk/scsi: fix notification suppression during AioContext polling)
- Resolves: bz#1790844
  (USB related fixes)
This commit is contained in:
Danilo C. L. de Paula 2020-01-15 19:44:01 +00:00
parent 1390e099ea
commit 686f1d075a
6 changed files with 538 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

113
kvm-spapr-Don-t-trigger-a-CAS-reboot-for-XICS-XIVE-mode-.patch Normal file
View File

@ -0,0 +1,113 @@
From f2aeed761d2dad14920fa08c977dc45564886d9b Mon Sep 17 00:00:00 2001
From: David Gibson <dgibson@redhat.com>
Date: Fri, 3 Jan 2020 01:15:12 +0000
Subject: [PATCH 1/5] spapr: Don't trigger a CAS reboot for XICS/XIVE mode
changeover
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
RH-Author: David Gibson <dgibson@redhat.com>
Message-id: <20200103011512.49129-2-dgibson@redhat.com>
Patchwork-id: 93261
O-Subject: [RHEL-AV-4.2 qemu-kvm PATCH 1/1] spapr: Don't trigger a CAS reboot for XICS/XIVE mode changeover
Bugzilla: 1733893
RH-Acked-by: Laurent Vivier <lvivier@redhat.com>
RH-Acked-by: Thomas Huth <thuth@redhat.com>
RH-Acked-by: Philippe Mathieu-Daudé <philmd@redhat.com>
From: David Gibson <david@gibson.dropbear.id.au>
PAPR allows the interrupt controller used on a POWER9 machine (XICS or
XIVE) to be selected by the guest operating system, by using the
ibm,client-architecture-support (CAS) feature negotiation call.
Currently, if the guest selects an interrupt controller different from the
one selected at initial boot, this causes the system to be reset with the
new model and the boot starts again. This means we run through the SLOF
boot process twice, as well as any other bootloader (e.g. grub) in use
before the OS calls CAS. This can be confusing and/or inconvenient for
users.
Thanks to two fairly recent changes, we no longer need this reboot. 1) we
now completely regenerate the device tree when CAS is called (meaning we
don't need special case updates for all the device tree changes caused by
the interrupt controller mode change), 2) we now have explicit code paths
to activate and deactivate the different interrupt controllers, rather than
just implicitly calling those at machine reset time.
We can therefore eliminate the reboot for changing irq mode, simply by
putting a call to spapr_irq_update_active_intc() before we call
spapr_h_cas_compose_response() (which gives the updated device tree to
the guest firmware and OS).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cedric Le Goater <clg@fr.ibm.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit 8deb8019d696c75e6ecaee7545026b62aba2f1bb)
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1733893
Signed-off-by: David Gibson <dgibson@redhat.com>
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
---
hw/ppc/spapr_hcall.c | 33 +++++++++++++--------------------
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 140f05c..05a7ca2 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1767,21 +1767,10 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
}
spapr->cas_pre_isa3_guest = !spapr_ovec_test(ov1_guest, OV1_PPC_3_00);
spapr_ovec_cleanup(ov1_guest);
- if (!spapr->cas_reboot) {
- /* If spapr_machine_reset() did not set up a HPT but one is necessary
- * (because the guest isn't going to use radix) then set it up here. */
- if ((spapr->patb_entry & PATE1_GR) && !guest_radix) {
- /* legacy hash or new hash: */
- spapr_setup_hpt_and_vrma(spapr);
- }
- spapr->cas_reboot =
- (spapr_h_cas_compose_response(spapr, args[1], args[2],
- ov5_updates) != 0);
- }
/*
- * Ensure the guest asks for an interrupt mode we support; otherwise
- * terminate the boot.
+ * Ensure the guest asks for an interrupt mode we support;
+ * otherwise terminate the boot.
*/
if (guest_xive) {
if (!spapr->irq->xive) {
@@ -1797,14 +1786,18 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
}
}
- /*
- * Generate a machine reset when we have an update of the
- * interrupt mode. Only required when the machine supports both
- * modes.
- */
+ spapr_irq_update_active_intc(spapr);
+
if (!spapr->cas_reboot) {
- spapr->cas_reboot = spapr_ovec_test(ov5_updates, OV5_XIVE_EXPLOIT)
- && spapr->irq->xics && spapr->irq->xive;
+ /* If spapr_machine_reset() did not set up a HPT but one is necessary
+ * (because the guest isn't going to use radix) then set it up here. */
+ if ((spapr->patb_entry & PATE1_GR) && !guest_radix) {
+ /* legacy hash or new hash: */
+ spapr_setup_hpt_and_vrma(spapr);
+ }
+ spapr->cas_reboot =
+ (spapr_h_cas_compose_response(spapr, args[1], args[2],
+ ov5_updates) != 0);
}
spapr_ovec_cleanup(ov5_updates);
--
1.8.3.1

106
kvm-usbredir-Prevent-recursion-in-usbredir_write.patch Normal file
View File

@ -0,0 +1,106 @@
From 8f6311159977b8ee4b78172caa411d3cee4d2ae5 Mon Sep 17 00:00:00 2001
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Date: Tue, 14 Jan 2020 20:23:30 +0000
Subject: [PATCH 4/5] usbredir: Prevent recursion in usbredir_write
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
RH-Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-id: <20200114202331.51831-2-dgilbert@redhat.com>
Patchwork-id: 93344
O-Subject: [RHEL-AV-8.2.0 qemu-kvm PATCH 1/2] usbredir: Prevent recursion in usbredir_write
Bugzilla: 1790844
RH-Acked-by: Peter Xu <peterx@redhat.com>
RH-Acked-by: Philippe Mathieu-Daudé <philmd@redhat.com>
RH-Acked-by: Gerd Hoffmann <kraxel@redhat.com>
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
I've got a case where usbredir_write manages to call back into itself
via spice; this patch causes the recursion to fail (0 bytes) the write;
this seems to avoid the deadlock I was previously seeing.
I can't say I fully understand the interaction of usbredir and spice;
but there are a few similar guards in spice and usbredir
to catch other cases especially onces also related to spice_server_char_device_wakeup
This case seems to be triggered by repeated migration+repeated
reconnection of the viewer; but my debugging suggests the migration
finished before this hits.
The backtrace of the hang looks like:
reds_handle_ticket
reds_handle_other_links
reds_channel_do_link
red_channel_connect
spicevmc_connect
usbredir_create_parser
usbredirparser_do_write
usbredir_write
qemu_chr_fe_write
qemu_chr_write
qemu_chr_write_buffer
spice_chr_write
spice_server_char_device_wakeup
red_char_device_wakeup
red_char_device_write_to_device
vmc_write
usbredirparser_do_write
usbredir_write
qemu_chr_fe_write
qemu_chr_write
qemu_chr_write_buffer
qemu_mutex_lock_impl
and we fail as we land through qemu_chr_write_buffer's lock
twice.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1752320
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20191218113012.13331-1-dgilbert@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 394642a8d3742c885e397d5bb5ee0ec40743cdc6)
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
---
hw/usb/redirect.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index e0f5ca6..97f2c3a 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -113,6 +113,7 @@ struct USBRedirDevice {
/* Properties */
CharBackend cs;
bool enable_streams;
+ bool in_write;
uint8_t debug;
int32_t bootindex;
char *filter_str;
@@ -290,6 +291,13 @@ static int usbredir_write(void *priv, uint8_t *data, int count)
return 0;
}
+ /* Recursion check */
+ if (dev->in_write) {
+ DPRINTF("usbredir_write recursion\n");
+ return 0;
+ }
+ dev->in_write = true;
+
r = qemu_chr_fe_write(&dev->cs, data, count);
if (r < count) {
if (!dev->watch) {
@@ -300,6 +308,7 @@ static int usbredir_write(void *priv, uint8_t *data, int count)
r = 0;
}
}
+ dev->in_write = false;
return r;
}
--
1.8.3.1

58
kvm-vfio-pci-Don-t-remove-irqchip-notifier-if-not-regist.patch Normal file
View File

@ -0,0 +1,58 @@
From e4631c00d8e9ee3608ef3196cbe8bec4841ee988 Mon Sep 17 00:00:00 2001
From: Peter Xu <peterx@redhat.com>
Date: Wed, 8 Jan 2020 15:04:57 +0000
Subject: [PATCH 2/5] vfio/pci: Don't remove irqchip notifier if not registered
RH-Author: Peter Xu <peterx@redhat.com>
Message-id: <20200108150457.12324-2-peterx@redhat.com>
Patchwork-id: 93291
O-Subject: [RHEL-AV-8.2.0 qemu-kvm PATCH 1/1] vfio/pci: Don't remove irqchip notifier if not registered
Bugzilla: 1782678
RH-Acked-by: Alex Williamson <alex.williamson@redhat.com>
RH-Acked-by: Cornelia Huck <cohuck@redhat.com>
RH-Acked-by: Auger Eric <eric.auger@redhat.com>
RH-Acked-by: Jens Freimann <jfreimann@redhat.com>
The kvm irqchip notifier is only registered if the device supports
INTx, however it's unconditionally removed. If the assigned device
does not support INTx, this will cause QEMU to crash when unplugging
the device from the system. Change it to conditionally remove the
notifier only if the notify hook is setup.
CC: Eduardo Habkost <ehabkost@redhat.com>
CC: David Gibson <david@gibson.dropbear.id.au>
CC: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-stable@nongnu.org # v4.2
Reported-by: yanghliu@redhat.com
Debugged-by: Eduardo Habkost <ehabkost@redhat.com>
Fixes: c5478fea27ac ("vfio/pci: Respond to KVM irqchip change notifier")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1782678
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
(cherry picked from commit 0446f8121723b134ca1d1ed0b73e96d4a0a8689d)
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
---
hw/vfio/pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 309535f..d717520 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -3100,7 +3100,9 @@ static void vfio_exitfn(PCIDevice *pdev)
vfio_unregister_req_notifier(vdev);
vfio_unregister_err_notifier(vdev);
pci_device_set_intx_routing_notifier(&vdev->pdev, NULL);
- kvm_irqchip_remove_change_notifier(&vdev->irqchip_change_notifier);
+ if (vdev->irqchip_change_notifier.notify) {
+ kvm_irqchip_remove_change_notifier(&vdev->irqchip_change_notifier);
+ }
vfio_disable_interrupts(vdev);
if (vdev->intx.mmap_timer) {
timer_free(vdev->intx.mmap_timer);
--
1.8.3.1

158
kvm-virtio-don-t-enable-notifications-during-polling.patch Normal file
View File

@ -0,0 +1,158 @@
From 351dd07d7b5e69cdf47260c9ea848c0c93cd2c8a Mon Sep 17 00:00:00 2001
From: Stefan Hajnoczi <stefanha@redhat.com>
Date: Thu, 9 Jan 2020 11:13:25 +0000
Subject: [PATCH 3/5] virtio: don't enable notifications during polling
RH-Author: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: <20200109111325.559557-2-stefanha@redhat.com>
Patchwork-id: 93298
O-Subject: [RHEL-AV-8.2.0 qemu-kvm PATCH 1/1] virtio: don't enable notifications during polling
Bugzilla: 1789301
RH-Acked-by: Paolo Bonzini <pbonzini@redhat.com>
RH-Acked-by: Sergio Lopez Pascual <slp@redhat.com>
RH-Acked-by: Michael S. Tsirkin <mst@redhat.com>
Virtqueue notifications are not necessary during polling, so we disable
them. This allows the guest driver to avoid MMIO vmexits.
Unfortunately the virtio-blk and virtio-scsi handler functions re-enable
notifications, defeating this optimization.
Fix virtio-blk and virtio-scsi emulation so they leave notifications
disabled. The key thing to remember for correctness is that polling
always checks one last time after ending its loop, therefore it's safe
to lose the race when re-enabling notifications at the end of polling.
There is a measurable performance improvement of 5-10% with the null-co
block driver. Real-life storage configurations will see a smaller
improvement because the MMIO vmexit overhead contributes less to
latency.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20191209210957.65087-1-stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d0435bc513e23a4961b6af20164d1c6c219eb4ea)
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
---
hw/block/virtio-blk.c | 9 +++++++--
hw/scsi/virtio-scsi.c | 9 +++++++--
hw/virtio/virtio.c | 12 ++++++------
include/hw/virtio/virtio.h | 1 +
4 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 4c357d2..c4e55fb 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -764,13 +764,16 @@ bool virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
{
VirtIOBlockReq *req;
MultiReqBuffer mrb = {};
+ bool suppress_notifications = virtio_queue_get_notification(vq);
bool progress = false;
aio_context_acquire(blk_get_aio_context(s->blk));
blk_io_plug(s->blk);
do {
- virtio_queue_set_notification(vq, 0);
+ if (suppress_notifications) {
+ virtio_queue_set_notification(vq, 0);
+ }
while ((req = virtio_blk_get_request(s, vq))) {
progress = true;
@@ -781,7 +784,9 @@ bool virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
}
}
- virtio_queue_set_notification(vq, 1);
+ if (suppress_notifications) {
+ virtio_queue_set_notification(vq, 1);
+ }
} while (!virtio_queue_empty(vq));
if (mrb.num_reqs) {
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 54108c0..e2cd1df 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -597,12 +597,15 @@ bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue *vq)
{
VirtIOSCSIReq *req, *next;
int ret = 0;
+ bool suppress_notifications = virtio_queue_get_notification(vq);
bool progress = false;
QTAILQ_HEAD(, VirtIOSCSIReq) reqs = QTAILQ_HEAD_INITIALIZER(reqs);
do {
- virtio_queue_set_notification(vq, 0);
+ if (suppress_notifications) {
+ virtio_queue_set_notification(vq, 0);
+ }
while ((req = virtio_scsi_pop_req(s, vq))) {
progress = true;
@@ -622,7 +625,9 @@ bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue *vq)
}
}
- virtio_queue_set_notification(vq, 1);
+ if (suppress_notifications) {
+ virtio_queue_set_notification(vq, 1);
+ }
} while (ret != -EINVAL && !virtio_queue_empty(vq));
QTAILQ_FOREACH_SAFE(req, &reqs, next, next) {
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 04716b5..3211135 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -432,6 +432,11 @@ static void virtio_queue_packed_set_notification(VirtQueue *vq, int enable)
}
}
+bool virtio_queue_get_notification(VirtQueue *vq)
+{
+ return vq->notification;
+}
+
void virtio_queue_set_notification(VirtQueue *vq, int enable)
{
vq->notification = enable;
@@ -3384,17 +3389,12 @@ static bool virtio_queue_host_notifier_aio_poll(void *opaque)
{
EventNotifier *n = opaque;
VirtQueue *vq = container_of(n, VirtQueue, host_notifier);
- bool progress;
if (!vq->vring.desc || virtio_queue_empty(vq)) {
return false;
}
- progress = virtio_queue_notify_aio_vq(vq);
-
- /* In case the handler function re-enabled notifications */
- virtio_queue_set_notification(vq, 0);
- return progress;
+ return virtio_queue_notify_aio_vq(vq);
}
static void virtio_queue_host_notifier_aio_poll_end(EventNotifier *n)
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index c32a815..6a20442 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -224,6 +224,7 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f, int version_id);
void virtio_notify_config(VirtIODevice *vdev);
+bool virtio_queue_get_notification(VirtQueue *vq);
void virtio_queue_set_notification(VirtQueue *vq, int enable);
int virtio_queue_ready(VirtQueue *vq);
--
1.8.3.1

77
kvm-xhci-recheck-slot-status.patch Normal file
View File

@ -0,0 +1,77 @@
From ab87c0ed2a8f0a626099261a3028bc34cfac3929 Mon Sep 17 00:00:00 2001
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Date: Tue, 14 Jan 2020 20:23:31 +0000
Subject: [PATCH 5/5] xhci: recheck slot status
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
RH-Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-id: <20200114202331.51831-3-dgilbert@redhat.com>
Patchwork-id: 93345
O-Subject: [RHEL-AV-8.2.0 qemu-kvm PATCH 2/2] xhci: recheck slot status
Bugzilla: 1790844
RH-Acked-by: Peter Xu <peterx@redhat.com>
RH-Acked-by: Philippe Mathieu-Daudé <philmd@redhat.com>
RH-Acked-by: Gerd Hoffmann <kraxel@redhat.com>
From: Gerd Hoffmann <kraxel@redhat.com>
Factor out slot status check into a helper function. Add an additional
check after completing transfers. This is needed in case a guest
queues multiple transfers in a row and a device unplug happens while
qemu processes them.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1786413
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20200107083606.12393-1-kraxel@redhat.com
(cherry picked from commit 236846a019c4f7aa3111026fc9a1fe09684c8978)
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
---
hw/usb/hcd-xhci.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index d2b9744..646c78c 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -1861,6 +1861,13 @@ static void xhci_kick_ep(XHCIState *xhci, unsigned int slotid,
xhci_kick_epctx(epctx, streamid);
}
+static bool xhci_slot_ok(XHCIState *xhci, int slotid)
+{
+ return (xhci->slots[slotid - 1].uport &&
+ xhci->slots[slotid - 1].uport->dev &&
+ xhci->slots[slotid - 1].uport->dev->attached);
+}
+
static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid)
{
XHCIState *xhci = epctx->xhci;
@@ -1878,9 +1885,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid)
/* If the device has been detached, but the guest has not noticed this
yet the 2 above checks will succeed, but we must NOT continue */
- if (!xhci->slots[epctx->slotid - 1].uport ||
- !xhci->slots[epctx->slotid - 1].uport->dev ||
- !xhci->slots[epctx->slotid - 1].uport->dev->attached) {
+ if (!xhci_slot_ok(xhci, epctx->slotid)) {
return;
}
@@ -1987,6 +1992,10 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid)
} else {
xhci_fire_transfer(xhci, xfer, epctx);
}
+ if (!xhci_slot_ok(xhci, epctx->slotid)) {
+ /* surprise removal -> stop processing */
+ break;
+ }
if (xfer->complete) {
/* update ring dequeue ptr */
xhci_set_ep_state(xhci, epctx, stctx, epctx->state);
--
1.8.3.1

27
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: 5%{?dist}
Release: 6%{?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
@ -125,6 +125,16 @@ Patch0021: 0021-Using-ip_deq-after-m_free-might-read-pointers-from-a.patch
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
# For bz#1733893 - Boot a guest with "-prom-env 'auto-boot?=false'", SLOF failed to enter the boot entry after input "boot" followed by "0 > " on VNC
Patch24: kvm-spapr-Don-t-trigger-a-CAS-reboot-for-XICS-XIVE-mode-.patch
# For bz#1782678 - qemu core dump after hot-unplugging the XXV710/XL710 PF
Patch25: kvm-vfio-pci-Don-t-remove-irqchip-notifier-if-not-regist.patch
# For bz#1789301 - virtio-blk/scsi: fix notification suppression during AioContext polling
Patch26: kvm-virtio-don-t-enable-notifications-during-polling.patch
# For bz#1790844 - USB related fixes
Patch27: kvm-usbredir-Prevent-recursion-in-usbredir_write.patch
# For bz#1790844 - USB related fixes
Patch28: kvm-xhci-recheck-slot-status.patch
BuildRequires: wget
BuildRequires: rpm-build
@ -1059,6 +1069,21 @@ useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin \
%changelog
* Wed Jan 15 2020 Danilo Cesar Lemes de Paula <ddepaula@redhat.com> - 4.2.0-6.el8
- kvm-spapr-Don-t-trigger-a-CAS-reboot-for-XICS-XIVE-mode-.patch [bz#1733893]
- kvm-vfio-pci-Don-t-remove-irqchip-notifier-if-not-regist.patch [bz#1782678]
- kvm-virtio-don-t-enable-notifications-during-polling.patch [bz#1789301]
- kvm-usbredir-Prevent-recursion-in-usbredir_write.patch [bz#1790844]
- kvm-xhci-recheck-slot-status.patch [bz#1790844]
- Resolves: bz#1733893
(Boot a guest with "-prom-env 'auto-boot?=false'", SLOF failed to enter the boot entry after input "boot" followed by "0 > " on VNC)
- Resolves: bz#1782678
(qemu core dump after hot-unplugging the XXV710/XL710 PF)
- Resolves: bz#1789301
(virtio-blk/scsi: fix notification suppression during AioContext polling)
- Resolves: bz#1790844
(USB related fixes)
* 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]