]> git.proxmox.com Git - mirror_qemu.git/commit - hw/s390x/s390-pci-bus.c
s390x/pci: Drop release timer and replace it with a flag
authorDavid Hildenbrand <david@redhat.com>
Wed, 30 Jan 2019 15:57:32 +0000 (16:57 +0100)
committerCornelia Huck <cohuck@redhat.com>
Mon, 4 Feb 2019 12:47:50 +0000 (13:47 +0100)
commit9f2a46b11139cd21c41f4d97c0416af6f9e76f7b
treeed81b026f08ecb19a4bcbc9d18095527cd588eca
parente0998fe8910435f0e818e5c9ac58d4d2d9144a98
s390x/pci: Drop release timer and replace it with a flag

Let's handle it similar to x86 ACPI PCI code and don't use a timer.
Instead, remember if an unplug request is pending and keep it pending
for eternity. (a follow up patch will process the request on
reboot).

We expect that a guest that is up and running, will process the unplug
request and trigger the unplug. This is normal operation, no timer needed.

If the guest does not react, this usually means something in the guest
is going wrong. Simply removing the device after 30 seconds does not
really sound like a good idea. It might sometimes be wanted, but I
consider this rather an "opt-in" decision as it might harm a guest not
prepared for it.

If we ever actually want a "forced/surprise removal", we will have to
implement something on top of the existing "device_del" framework. E.g.
also x86 might want to do a forced/surprise removal of PCI devices under
some conditions. "device_del X, forced=true" could be an option and will
require changes to the hotplug handler infrastructure.

This will then move the responsibility on when to do a forced removal
to a higher level. Doing a forced removal right now over-complicates
things and doesn't really seem to be required.

Let's allow to send multiple requests.

Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190130155733.32742-6-david@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
hw/s390x/s390-pci-bus.c
hw/s390x/s390-pci-bus.h