From fe66ecbf55cdab181a1ea057f8685eea08d564d9 Mon Sep 17 00:00:00 2001 From: MSVSphere Packaging Team Date: Tue, 11 Jul 2023 17:07:46 +0300 Subject: [PATCH] import qemu-kvm-7.2.0-14.el9_2.1 --- ...-allow-repeating-hot-unplug-requests.patch | 83 +++++++++++++++++++ SPECS/qemu-kvm.spec | 9 +- 2 files changed, 91 insertions(+), 1 deletion(-) create mode 100644 SOURCES/kvm-acpi-pcihp-allow-repeating-hot-unplug-requests.patch diff --git a/SOURCES/kvm-acpi-pcihp-allow-repeating-hot-unplug-requests.patch b/SOURCES/kvm-acpi-pcihp-allow-repeating-hot-unplug-requests.patch new file mode 100644 index 0000000..a4fb6b1 --- /dev/null +++ b/SOURCES/kvm-acpi-pcihp-allow-repeating-hot-unplug-requests.patch @@ -0,0 +1,83 @@ +From d110c11b5658df93533698fdb428455f5e770866 Mon Sep 17 00:00:00 2001 +From: Igor Mammedov +Date: Tue, 18 Apr 2023 11:04:49 +0200 +Subject: [PATCH] acpi: pcihp: allow repeating hot-unplug requests + +RH-Author: Igor Mammedov +RH-MergeRequest: 280: acpi: pcihp: allow repeating hot-unplug requests +RH-Bugzilla: 2203745 +RH-Acked-by: Ani Sinha +RH-Acked-by: MST +RH-Acked-by: Julia Suvorova +RH-Commit: [1/1] e884ac48ebd43c3ebdbc65b01ce5ad75f4cb9284 + +with Q35 using ACPI PCI hotplug by default, user's request to unplug +device is ignored when it's issued before guest OS has been booted. +And any additional attempt to request device hot-unplug afterwards +results in following error: + + "Device XYZ is already in the process of unplug" + +arguably it can be considered as a regression introduced by [2], +before which it was possible to issue unplug request multiple +times. + +Accept new uplug requests after timeout (1ms). This brings ACPI PCI +hotplug on par with native PCIe unplug behavior [1] and allows user +to repeat unplug requests at propper times. +Set expire timeout to arbitrary 1msec so user won't be able to +flood guest with SCI interrupts by calling device_del in tight loop. + +PS: +ACPI spec doesn't mandate what OSPM can do with GPEx.status +bits set before it's booted => it's impl. depended. +Status bits may be retained (I tested with one Windows version) +or cleared (Linux since 2.6 kernel times) during guest's ACPI +subsystem initialization. +Clearing status bits (though not wrong per se) hides the unplug +event from guest, and it's upto user to repeat device_del later +when guest is able to handle unplug requests. + +1) 18416c62e3 ("pcie: expire pending delete") +2) +Fixes: cce8944cc9ef ("qdev-monitor: Forbid repeated device_del") +Signed-off-by: Igor Mammedov +Acked-by: Gerd Hoffmann +CC: mst@redhat.com +CC: anisinha@redhat.com +CC: jusual@redhat.com +CC: kraxel@redhat.com +Message-Id: <20230418090449.2155757-1-imammedo@redhat.com> +Reviewed-by: Michael S. Tsirkin +Signed-off-by: Michael S. Tsirkin +Reviewed-by: Ani Sinha +(cherry picked from commit 0f689cf5ada4d5df5ab95c7f7aa9fc221afa855d) +Signed-off-by: Igor Mammedov +--- + hw/acpi/pcihp.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c +index 84d75e6b84..a2a3738b46 100644 +--- a/hw/acpi/pcihp.c ++++ b/hw/acpi/pcihp.c +@@ -429,6 +429,16 @@ void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev, + * acpi_pcihp_eject_slot() when the operation is completed. + */ + pdev->qdev.pending_deleted_event = true; ++ /* if unplug was requested before OSPM is initialized, ++ * linux kernel will clear GPE0.sts[] bits during boot, which effectively ++ * hides unplug event. And than followup qmp_device_del() calls remain ++ * blocked by above flag permanently. ++ * Unblock qmp_device_del() by setting expire limit, so user can ++ * repeat unplug request later when OSPM has been booted. ++ */ ++ pdev->qdev.pending_deleted_expires_ms = ++ qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL); /* 1 msec */ ++ + s->acpi_pcihp_pci_status[bsel].down |= (1U << slot); + acpi_send_event(DEVICE(hotplug_dev), ACPI_PCI_HOTPLUG_STATUS); + } +-- +2.39.1 + diff --git a/SPECS/qemu-kvm.spec b/SPECS/qemu-kvm.spec index c72d59b..f0e1ef3 100644 --- a/SPECS/qemu-kvm.spec +++ b/SPECS/qemu-kvm.spec @@ -148,7 +148,7 @@ Obsoletes: %{name}-block-ssh <= %{epoch}:%{version} \ Summary: QEMU is a machine emulator and virtualizer Name: qemu-kvm Version: 7.2.0 -Release: 14%{?rcrel}%{?dist}%{?cc_suffix} +Release: 14%{?rcrel}%{?dist}%{?cc_suffix}.1 # Epoch because we pushed a qemu-1.0 package. AIUI this can't ever be dropped # Epoch 15 used for RHEL 8 # Epoch 17 used for RHEL 9 (due to release versioning offset in RHEL 8.5) @@ -416,6 +416,8 @@ Patch133: kvm-target-i386-Fix-32-bit-AD-CO-X-insns-in-64-bit-mode.patch Patch134: kvm-target-i386-Fix-BZHI-instruction.patch # For bz#2156876 - [virtual network][rhel7.9_guest] qemu-kvm: vhost vring error in virtqueue 1: Invalid argument (22) Patch135: kvm-intel-iommu-fail-DEVIOTLB_UNMAP-without-dt-mode.patch +# For bz#2203745 - Disk detach is unsuccessful while the guest is still booting [rhel-9.2.0.z] +Patch136: kvm-acpi-pcihp-allow-repeating-hot-unplug-requests.patch %if %{have_clang} BuildRequires: clang @@ -1446,6 +1448,11 @@ useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin \ %endif %changelog +* Thu May 25 2023 Miroslav Rezanina - 7.2.0-14.el9_2.1 +- kvm-acpi-pcihp-allow-repeating-hot-unplug-requests.patch [bz#2203745] +- Resolves: bz#2203745 + (Disk detach is unsuccessful while the guest is still booting [rhel-9.2.0.z]) + * Mon Mar 20 2023 Miroslav Rezanina - 7.2.0-14 - Rebuild for 9.2 release - Resolves: bz#2173590