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 Mon, Dec 28, 2020 at 03:05:43PM +0800, Jason Wang wrote:
> 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
> > > > this.
> > > 
> > > 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.
> Thanks

Because device is expected to just stop:

	None of the virtqueues
	of a device are live once the device has been reset.

and it's driver's job to recover buffers:

	Thus a driver MUST ensure a virtqueue isn't live (by device reset) before removing exposed buffers.

what happened to buffers which were not used?

I think it's a quality of implementation/device specific issue, e.g. for net:
for transmit, if device sends a packet without using the buffer,
then driver will resend the packet leading to duplicates.
for receive, it's a packet drop, slightly less of a problem.

my question is whether such behaviour is sufficient for migration?
if not can we really describe it generally? it's possible we need to
describe it per device type.


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