On Wed, Jun 07, 2017 at 02:56:57PM -0400, Paolo Bonzini wrote:
>
> > > This could be documented,
> >
> > It is documented AFAIK. Pls take a look at the spec documentation.
>
> Found it now. It's not under GET_VRING_BASE, it's under "starting
> and stopping rings"---fair enough.
>
> In the case of vhost-user-scsi, however, QEMU also must not proceed
> until vhost-user-scsi has drained the pending I/O---and this pending
> I/O would be completed _after_ QEMU has sent GET_VRING_BASE.
Weird. Doesn't QEMU wait for response to GET_VRING_BASE?
I think it does since we migrate the returned value.
Spec says:
Client must only process each ring when it is started.
so this isn't expected. I guess whoever wrote vhost-user-scsi
understood "process" as "start processing".
What was intended is reading or writing any part of ring.
The used ring must not be updated after ring is stopped.
A spec clarification might in order.
> Is this handled by VHOST_USER_PROTOCOL_F_REPLY_ACK already? If so,
> migration would be denied if the server lacks that protocol feature.
>
> Paolo
GET_VRING_BASE does not need an ack, after respoding ring should
be stopped.
> > > but perhaps it's best to add a START_STOP
> > > feature and message to the vhost-user protocol?
> >
> > We just never need to GET_VRING_BASE if ring keeps going -
> > makes no sense since base gets invalidated immediately.
> >
> >
> >
> > > The feature then can be optional for vhost-user-net and mandatory for
> > > vhost-user-scsi. When this is done we can remove .unmigratable.
> > >
> > > Thanks,
> > >
> > > Paolo
> >
> > If vhost-user-scsi does not stop the ring after responding to
> > GET_VRING_BASE, it's just a bug that needs to be fixed.
> >
> > > > >
> > > > > Can you please send a version of your patch that uses .unmigratable?
> > > >
> > > > Sure I can do that. We can work on the migration later on.
> > > >
> > > > >
> > > > > I'll send a v6 that momentarily drops vhost-scsi, but I intend to
> > > > > include it again in the next pull request.
> > > >
> > > > Sounds good to me.
> > > >
> > > > Felipe
> > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Paolo
> > > >
> > > >
> >
