[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [qemu-s390x] [PATCH v2 5/6] s390x/pci: Drop release tim

From: David Hildenbrand
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v2 5/6] s390x/pci: Drop release timer and replace it with a flag
Date: Thu, 31 Jan 2019 22:12:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 31.01.19 21:33, Collin Walling wrote:
> On 1/30/19 10:57 AM, David Hildenbrand 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
> nit: "over-complicates" or "over complicates"
>> things and doesn't really.
> "...and doesn't really." sounds odd to me :)

Hmm, I guess this was meant to be

"and doesn't really seem to be required." :)

>> Let's allow to send multiple requests.
>> Signed-off-by: David Hildenbrand <address@hidden>
>> ---
> Just a quick clean up of the commit message, and all is good.


> Reviewed-by: Collin Walling <address@hidden>



David / dhildenb

reply via email to

[Prev in Thread] Current Thread [Next in Thread]