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 2020/12/27 äå7:12, Michael S. Tsirkin wrote:
On Fri, Dec 25, 2020 at 02:45:28PM +0800, Jason Wang wrote:
I tend to say, that from a perspective of the driver, all requests that
are available, and not yet used, are in-flight. So we have to be very
careful when wording this requirement, to avoid misunderstandings. I
don't think the first RFC is good enough. I will think some more about

Yes, I agree. The problem is that the spec doesn't describe how device work,
so if we want to be more accurate, it might require some work not only for
stop but also for e.g reset (something like in flight has been used by the
spec in that case).
You probably mean the DEVICE_NEEDS_RESET description, right?

	For example, the driver can't assume requests in flight will be
	completed if DEVICE_NEEDS_RESET is set, nor can it assume that
	they have not been completed.  A good implementation will try to
	recover by issuing a reset.

yes, DEVICE_NEEDS_RESET is unfortunately underspecified which likely
is related to the fact it is not widely implemented.

For both NEEDS_RESET and device reset.

For NEEDS_RESET, we use "in flight" and "completed" without an actual definition.

For device reset, we don't even define what is the device expected (e.g how are "in flight" requests expected to be processed) to behave.


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