Re: [virtio-comment] [PATCH V2 2/2] virtio: introduce STOP status bit

[Cornelia Huck <cohuck@redhat.com>]

On Tue, Jul 13 2021, Jason Wang <jasowang@redhat.com> wrote:

> å 2021/7/13 äå7:31, Cornelia Huck åé:
>> On Tue, Jul 13 2021, Jason Wang <jasowang@redhat.com> wrote:
>>
>>> å 2021/7/13 äå4:19, Cornelia Huck åé:
>>>> On Tue, Jul 13 2021, Jason Wang <jasowang@redhat.com> wrote:
>>>>
>>>>> å 2021/7/12 äå5:57, Stefan Hajnoczi åé:
>>>>>> When migrating a guest with many VIRTIO devices a busy waiting approach
>>>>>> extends downtime if implemented sequentially (stopping one device at a
>>>>>> time).
>>>>> Well. You need some kinds of waiting for sure, the device/DMA needs
>>>>> sometime to be stopped. The downtime is determined by a specific virtio
>>>>> implementation which is hard to be restricted at the spec level. We can
>>>>> clarify that the device must set the STOP bit in e.g 100ms.
>>>> I don't think we can introduce arbitrary upper bounds here. At most, we
>>>> can say that the device SHOULD try to set the STOP bit as early as
>>>> possible (and make use of the mechanism to expose in-flight buffers.)
>>>
>>> Yes, that's my understanding.
>>>
>>>
>>>> If we want to avoid polling for the STOP bit, we need some kind of
>>>> notification mechanism, I guess. For ccw, I'd just use a channel
>>>> command to stop the device; completion of that channel program would
>>>> indicate that the device is done with the stop procedure.
>>>
>>> A question, is interrupt used for such notification, or the VMM can
>>> choose to poll for the completion?
>> You can poll for the subchannel to become status pending.
>>
>>>
>>>> Not sure how
>>>> well that translates to other transports.
>>>
>>> Actually, it's not necessarily a busy polling. VMM can schedule other
>>> process in and recheck the bit periodically.
>>>
>>> Or as you mentioned before, we can use some kind of interrupt but it
>>> would be more complicated than the simple status bit. It's better to
>>> introduce the interrupt only if the status bit doesn't fit.
>> At least for ccw, waiting for the status bit to be set also involves an
>> interrupt or polling (we use another channel program to retrieve the
>> status.) A dedicated channel command would actually be better, as the
>> interrupt/status pending would already inform us of success.
>
>
> So it looks to me it doesn't conflict with this design: the device must 
> wait for the device to be stopped to signal the success of the ccw command?

Yes, the difference is mainly how that information can be extracted.