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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Dec 29, 2020 at 04:04:27AM -0500, Jason Wang wrote:
> > > > > 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.
> > > 
> > > 
> > > For networking device, it should be possible (packet could be dropped or
> > > duplicated). But I'm not sure it works for other device. E.g for the block
> > > devices that needs to communicate with a remote backend. Waat's more
> > > important, my understadning is that the intermediate state is something
> > > that
> > > we need to avoid (hard to be migrated anyhow).
> > 
> > The difficulty is on the device side though, so why not say: if it wants to
> > flush IO that's up to it.
> 
> Do you mean to introduce a device specific way to flush IO? If yes, it
> actually introduces a new intermediate state implicitly:
> 
> 1) device is stopped
> 2) device is stopped and IO is flushed
> 
> This looks more complicated than a single new state:
> 
> 1) device is stopped and IO is flushed
> 
> Thanks

I thought some more about it, if we call a buffer which was
made available by driver but not yet used by device,
a cancelled buffer, then maybe we can specify
the behaviour by explaining that it should be possible to
retry any cancelled buffer, that is make it available again,
and achieve the same effect as if it was used.
For example, any reads without side effects can be just
ignored even if they might have modified guest memory.

-- 
MST