Re: [virtio-comment] [PATCH V2 2/2] virtio: introduce STOP status bit

[Jason Wang <jasowang@redhat.com>]

å 2021/7/13 äå7:31, Cornelia Huck åé:
> On Tue, Jul 13 2021, Jason Wang <jasowang@redhat.com> wrote:
>
> > å 2021/7/13 äå4:19, Cornelia Huck åé:
> > > On Tue, Jul 13 2021, Jason Wang <jasowang@redhat.com> wrote:
> > >
> > > > å 2021/7/12 äå5:57, Stefan Hajnoczi åé:
> > > > > When migrating a guest with many VIRTIO devices a busy waiting approach
> > > > > extends downtime if implemented sequentially (stopping one device at a
> > > > > time).
> > > > Well. You need some kinds of waiting for sure, the device/DMA needs
> > > > sometime to be stopped. The downtime is determined by a specific virtio
> > > > implementation which is hard to be restricted at the spec level. We can
> > > > clarify that the device must set the STOP bit in e.g 100ms.
> > > I don't think we can introduce arbitrary upper bounds here. At most, we
> > > can say that the device SHOULD try to set the STOP bit as early as
> > > possible (and make use of the mechanism to expose in-flight buffers.)
> >
> > Yes, that's my understanding.
> >
> >
> > > If we want to avoid polling for the STOP bit, we need some kind of
> > > notification mechanism, I guess. For ccw, I'd just use a channel
> > > command to stop the device; completion of that channel program would
> > > indicate that the device is done with the stop procedure.
> >
> > A question, is interrupt used for such notification, or the VMM can
> > choose to poll for the completion?
> You can poll for the subchannel to become status pending.
>
> > > Not sure how
> > > well that translates to other transports.
> >
> > Actually, it's not necessarily a busy polling. VMM can schedule other
> > process in and recheck the bit periodically.
> >
> > Or as you mentioned before, we can use some kind of interrupt but it
> > would be more complicated than the simple status bit. It's better to
> > introduce the interrupt only if the status bit doesn't fit.
> At least for ccw, waiting for the status bit to be set also involves an
> interrupt or polling (we use another channel program to retrieve the
> status.) A dedicated channel command would actually be better, as the
> interrupt/status pending would already inform us of success.


So it looks to me it doesn't conflict with this design: the device must 
wait for the device to be stopped to signal the success of the ccw command?

Thanks


>