qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 1/2] s390x/pci: Introduce unplug requests and


From: David Hildenbrand
Subject: Re: [Qemu-devel] [PATCH v3 1/2] s390x/pci: Introduce unplug requests and split unplug handler
Date: Tue, 29 Jan 2019 21:27:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 29.01.19 17:54, Pierre Morel wrote:
> On 29/01/2019 16:14, David Hildenbrand wrote:
>> On 29.01.19 14:31, Pierre Morel wrote:
>>> On 21/01/2019 14:42, David Hildenbrand wrote:
>>>> PCI on s390x is really weird and how it was modeled in QEMU might not have
>>>> been the right choice. Anyhow, right now it is the case that:
>>>> - Hotplugging a PCI device will silently create a zPCI device
>>>>     (if none is provided)
>>>> - Hotunplugging a zPCI device will unplug the PCI device (if any)
>>>> - Hotunplugging a PCI device will unplug also the zPCI device
>>>> As far as I can see, we can no longer change this behavior. But we
>>>> should fix it.
> 
> 
>>> So unplugging PCI first will deny the guest any possibility to smoothly
>>> relinquish a device.
>>>
>>>
>>> Is it possible the other way around?
>>
>> Maybe, but it does not really matter. We unplug both devices
>> synchronously, without the guest recognizing the order. We always have
>> the unplug request first that notifies the guest. When we get an ACK
>> from the guest, we can unpplug both devices in any order.
>>
>> (and if we want to change the order, we should do it in a separate
>> patch, this patch does not change the order, just refactors the code)
> 
> 
> If it is done atomically, then I have no objection.

Yes, this is atomically. It is two separate steps, but only logically.
The guest cannot observe it.

Thanks!

> 
> Regards,
> Pierre
> 
> 
> 


-- 

Thanks,

David / dhildenb



reply via email to

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