From: Cornelia Huck <cohuck@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
Collin Walling <walling@linux.ibm.com>,
Thomas Huth <thuth@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Richard Henderson <rth@twiddle.net>,
Pierre Morel <pmorel@linux.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v2 5/6] s390x/pci: Drop release timer and replace it with a flag
Date: Fri, 1 Feb 2019 11:39:48 +0100 [thread overview]
Message-ID: <20190201113948.1bae8beb.cohuck@redhat.com> (raw)
In-Reply-To: <20190130155733.32742-6-david@redhat.com>
On Wed, 30 Jan 2019 16:57:32 +0100
David Hildenbrand <david@redhat.com> wrote:
> 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 overcomplicates
> things and doesn't really.
>
> Let's allow to send multiple requests.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> hw/s390x/s390-pci-bus.c | 38 +++++++-------------------------------
> hw/s390x/s390-pci-bus.h | 3 +--
> 2 files changed, 8 insertions(+), 33 deletions(-)
Thanks, applied.
next prev parent reply other threads:[~2019-02-01 10:39 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 15:57 [Qemu-devel] [PATCH v2 0/6] s390x/pci: remaining hot/un)plug patches David Hildenbrand
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 1/6] s390x/pci: Fix primary bus number for PCI bridges David Hildenbrand
2019-02-04 22:58 ` Collin Walling
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 2/6] s390x/pci: Fix hotplugging of " David Hildenbrand
2019-02-04 22:48 ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-02-04 23:43 ` David Hildenbrand
2019-02-05 9:24 ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 3/6] s390x/pci: Warn when adding PCI devices without the 'zpci' feature David Hildenbrand
2019-02-04 20:19 ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-02-04 21:54 ` David Hildenbrand
2019-02-04 22:42 ` Collin Walling
2019-02-04 22:45 ` David Hildenbrand
2019-02-05 9:32 ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 4/6] s390x/pci: Introduce unplug requests and split unplug handler David Hildenbrand
2019-01-31 20:40 ` Collin Walling
2019-01-31 21:11 ` David Hildenbrand
2019-02-01 10:38 ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 5/6] s390x/pci: Drop release timer and replace it with a flag David Hildenbrand
2019-01-31 20:33 ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-01-31 21:12 ` David Hildenbrand
2019-01-31 21:21 ` [Qemu-devel] " David Hildenbrand
2019-02-01 10:08 ` Cornelia Huck
2019-02-01 10:37 ` David Hildenbrand
2019-02-01 10:42 ` Cornelia Huck
2019-02-01 10:39 ` Cornelia Huck [this message]
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 6/6] s390x/pci: Unplug remaining requested devices on pcihost reset David Hildenbrand
2019-01-31 20:26 ` Collin Walling
2019-01-31 21:13 ` David Hildenbrand
2019-02-01 10:19 ` Cornelia Huck
2019-02-01 15:06 ` David Hildenbrand
2019-02-05 9:35 ` Cornelia Huck
2019-01-30 16:27 ` [Qemu-devel] [PATCH v2 0/6] s390x/pci: remaining hot/un)plug patches Cornelia Huck
2019-01-31 20:43 ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-01-31 21:21 ` David Hildenbrand
2019-02-01 8:35 ` Cornelia Huck
2019-02-01 9:18 ` David Hildenbrand
2019-02-01 15:44 ` Collin Walling
2019-02-05 9:55 ` [Qemu-devel] " Cornelia Huck
2019-02-05 9:55 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190201113948.1bae8beb.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
--cc=walling@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.