[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [PATCH RFC] virtio: introduce VIRTIO_F_DEVICE_STOP
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]