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

[Jason Wang <jasowang@redhat.com>]

å 2021/7/15 äå5:16, Stefan Hajnoczi åé:
> On Thu, Jul 15, 2021 at 09:35:13AM +0800, Jason Wang wrote:
> > å 2021/7/14 äå11:07, Stefan Hajnoczi åé:
> > > On Wed, Jul 14, 2021 at 06:29:28PM +0800, Jason Wang wrote:
> > > > And as I've stated several times, virtqueue is the interface or transport
> > > > which carries the commands for implementing specific semantics. It doesn't
> > > > conflict with what is proposed in this patch.
> > > The abstract operations for stopping the device and fetching virtqueue
> > > state sound good to me, but I don't think a Device Status field STOP bit
> > > should be added. An out-of-band stop operation would support devices
> > > that take a long time to stop better.
> >
> > So the long time request is not something that is introduced by the STOP
> > bit. Spec already use that for reset.
> Reset doesn't affect migration downtime. The register polling approach
> is problematic during migration downtime because it's difficult to stop
> multiple devices and do other downtime cleanup concurrently.


This part I don't understand. We don't have an centralized control path 
that is used for each virtual functions.

VMM is free to stop multiple devices and poll for all those device status?


> Stopping
> devices sequentially increases migration downtime, so I think the
> interface should encourage concurrently stopping multiple devices.
>
> I think you and Cornelia discussed that an interrupt could be added to
> solve this problem. That would address my concerns about the STOP bit.


The problems are:

1) if we generate an interrupt after STOP, it breaks the STOP semantic 
where the device should not generate any interrupt
2) if we generate an interrupt before STOP, we may end up with race 
conditions

Thanks


> Stefan