[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.
>
Thanks!
> Reviewed-by: Collin Walling <address@hidden>
>
--
Thanks,
David / dhildenb
- [Qemu-devel] [PATCH v2 0/6] s390x/pci: remaining hot/un)plug patches, David Hildenbrand, 2019/01/30
- [Qemu-devel] [PATCH v2 1/6] s390x/pci: Fix primary bus number for PCI bridges, David Hildenbrand, 2019/01/30
- [Qemu-devel] [PATCH v2 2/6] s390x/pci: Fix hotplugging of PCI bridges, David Hildenbrand, 2019/01/30
- [Qemu-devel] [PATCH v2 4/6] s390x/pci: Introduce unplug requests and split unplug handler, David Hildenbrand, 2019/01/30
- [Qemu-devel] [PATCH v2 3/6] s390x/pci: Warn when adding PCI devices without the 'zpci' feature, David Hildenbrand, 2019/01/30
- [Qemu-devel] [PATCH v2 5/6] s390x/pci: Drop release timer and replace it with a flag, David Hildenbrand, 2019/01/30
- [Qemu-devel] [PATCH v2 6/6] s390x/pci: Unplug remaining requested devices on pcihost reset, David Hildenbrand, 2019/01/30
- Re: [Qemu-devel] [PATCH v2 0/6] s390x/pci: remaining hot/un)plug patches, Cornelia Huck, 2019/01/30
- Re: [Qemu-devel] [qemu-s390x] [PATCH v2 0/6] s390x/pci: remaining hot/un)plug patches, Collin Walling, 2019/01/31