OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[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
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

I 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?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]