Re: [virtio-comment] [PATCH RFC] virtio: introduce VIRTIO_F_DEVICE_STOP

[Halil Pasic <pasic@linux.ibm.com>]

On Sun, 27 Dec 2020 05:00:05 -0500
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Fri, Dec 25, 2020 at 08:38:35AM +0100, Halil Pasic wrote:
> >When driver is trying to set DEVICE_STOPPED, the device MUST not
> >process new avail requests and MUST complete all requests that is
> >currently processing before setting DEVICE_STOPPED.
> 
> ...
> 
> > Since we have a synchronous API setting DEVICE_STOPPED would also have to
> > block until all in-flight requests are completed.
> 
> Judging from the surrounding discussion,
> when you say complete you seem to mean "use", and

My intention was merely to paraphrase Jason's proposal which says:

+When driver is trying to set DEVICE_STOPPED, the device MUST not
+process new avail requests and MUST complete all requests that is
+currently processing before setting DEVICE_STOPPED.

> I'm not sure how you define in flight, but
> it seems there could be many of these (up to a full queue?)

In the follow-on discussion 'in-flight' emerged as an alternative to
'all requests that is currently processing' form the proposed text.

A large part of the discussion is, IMHO, about finding precise
definitions, for what the quoted paragraph is trying to express.

> so waiting for all available buffers to be
> used might indeed require an asynchronous interface,
> which gets complex very quickly.
> 
> However wouldn't it be possible for device to just cancel
> processing available buffers even if it started processing
> them? Some buffers could be in indeterminate state
> (e.g. we might not have a way to know how much data did
> device have time to write into a buffer).
> 

Maybe Jason can answer this one.

> Making it clearer what does "complete" mean here might help.
> 

I think what we are trying to accomplish here, is avoiding, having
non-standardised state in device (that can not be dropped) when
migrating. 

I'm still struggling with wrapping my mind around the problem. AFAIU
migration and migratability is not really a feature of the virtio
standard, but can be a feature of it's implementation
(e.g. QEMU & KVM), where the standard does help a great deal by having
certain aspects of the operation and interaction nailed down.

Regards,
Halil 

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/