Merge ~sergiodj/ubuntu/+source/qemu:allow-repeating-hot-unplug-lunar into ubuntu/+source/qemu:ubuntu/lunar-devel

[Sergio Durigan Junior]

This MP is the Lunar version of https://code.launchpad.net/~sergiodj/ubuntu/+source/qemu/+git/qemu/+merge/443231.

The backported patch is exactly the same. There is an extensive Test Plan in the bug if you'd like to perform more tests.

PPA: https://launchpad.net/~sergiodj/+archive/ubuntu/qemu

dep8 results:

Results: (from http://autopkgtest.ubuntu.com/results/autopkgtest-lunar-sergiodj-qemu/?format=plain)
  qemu @ arm64:
    28.05.23 05:43:38 Log 🗒️ ✅ Triggers: qemu/1:7.2+dfsg-5ubuntu2.1
  qemu @ armhf:
    30.05.23 07:52:02 Log 🗒️ ✅ Triggers: qemu/1:7.2+dfsg-5ubuntu2.1
  qemu @ ppc64el:
    30.05.23 00:24:20 Log 🗒️ ✅ Triggers: qemu/1:7.2+dfsg-5ubuntu2.1

I'll post the results for amd64 and s390x when they finish running.

[Lena Voytek (lvoytek)]

LGTM, same comments as the jammy mp

review: Approve

[git-ubuntu bot (git-ubuntu-bot)]

Approvers: sergiodj, lvoytek
Uploaders: sergiodj, lvoytek
MP auto-approved

review: Approve

[Sergio Durigan Junior (sergiodj)]

Uploaded:

$ dput qemu_7.2+dfsg-5ubuntu2.1_source.changes
Trying to upload package to ubuntu
Checking signature on .changes
gpg: /home/sergio/work/qemu/qemu_7.2+dfsg-5ubuntu2.1_source.changes: Valid signature from 106DA1C8C3CBBF14
Checking signature on .dsc
gpg: /home/sergio/work/qemu/qemu_7.2+dfsg-5ubuntu2.1.dsc: Valid signature from 106DA1C8C3CBBF14
Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading qemu_7.2+dfsg-5ubuntu2.1.dsc: done.
  Uploading qemu_7.2+dfsg-5ubuntu2.1.debian.tar.xz: done.
  Uploading qemu_7.2+dfsg-5ubuntu2.1_source.buildinfo: done.
  Uploading qemu_7.2+dfsg-5ubuntu2.1_source.changes: done.
Successfully uploaded packages.

diff --git a/debian/changelog b/debian/changelog
index 0450c1e..4064911 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+qemu (1:7.2+dfsg-5ubuntu2.1) lunar; urgency=medium
+
+  * d/p/u/allow-repeating-hot-unplug-requests.patch: Allow repeating
+    hot-unplug requests by making ACPI PCI able to requeue them.
+    (LP: #2018733)
+
+ -- Sergio Durigan Junior <[e-mail]>  Fri, 26 May 2023 15:57:03 -0400
+
 qemu (1:7.2+dfsg-5ubuntu2) lunar; urgency=medium
 
   * Fix FTBFS with glibc >= 2.36. (LP: #2015418)
diff --git a/debian/patches/series b/debian/patches/series
index 204d249..fe2dc60 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -68,3 +68,4 @@ ubuntu/pre-bionic-256k-ipxe-efi-roms.patch
 ubuntu/qboot-Disable-LTO-for-ELF-binary-build-step.patch
 ubuntu/fix-ftbfs-glibc-revert-compat-ioctl-defs.patch
 ubuntu/fix-ftbfs-glibc-sys-mount-h.patch
+ubuntu/allow-repeating-hot-unplug-requests.patch
diff --git a/debian/patches/ubuntu/allow-repeating-hot-unplug-requests.patch b/debian/patches/ubuntu/allow-repeating-hot-unplug-requests.patch
new file mode 100644
index 0000000..45ec3c1
--- /dev/null
+++ b/debian/patches/ubuntu/allow-repeating-hot-unplug-requests.patch
@@ -0,0 +1,74 @@
+From 0f689cf5ada4d5df5ab95c7f7aa9fc221afa855d Mon Sep 17 00:00:00 2001
+From: Igor Mammedov <[e-mail]>
+Date: Tue, 18 Apr 2023 11:04:49 +0200
+Subject: [PATCH] acpi: pcihp: allow repeating hot-unplug requests
+
+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 <[e-mail]>
+Acked-by: Gerd Hoffmann <[e-mail]>
+CC: [e-mail]
+CC: [e-mail]
+CC: [e-mail]
+CC: [e-mail]
+Message-Id: <[e-mail]>
+Reviewed-by: Michael S. Tsirkin <[e-mail]>
+Signed-off-by: Michael S. Tsirkin <[e-mail]>
+Reviewed-by: Ani Sinha <[e-mail]>
+
+Origin: upstream, https://gitlab.com/qemu-project/qemu/-/commit/0f689cf5ada4
+Bug: https://gitlab.com/libvirt/libvirt/-/issues/309
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2018733
+---
+ hw/acpi/pcihp.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+Index: qemu/hw/acpi/pcihp.c
+===================================================================
+--- a/hw/acpi/pcihp.c	2023-05-18 15:08:26.031339792 -0400
++++ b/hw/acpi/pcihp.c	2023-05-18 15:08:26.027339825 -0400
+@@ -429,6 +429,16 @@
+      * 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);
+ }