[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 2021/1/12 äå6:54, Michael S. Tsirkin wrote:
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 ThanksI thought some more about it, if we call a buffer which was made available by driver but not yet used by device,
For "used by device" you meant posting entries to used ring?
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.
Right, but how about the buffer that can't be retried? Or you meant we leave that to a specific device to handle?
THanks
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]