On Thu, May 26, 2022 at 8:54 PM Parav Pandit <parav@xxxxxxxxxx> wrote: > > > > > From: Eugenio Pérez <eperezma@xxxxxxxxxx> > > Sent: Thursday, May 26, 2022 8:44 AM > > > Implement stop operation for vdpa_sim devices, so vhost-vdpa will offer > > > > that backend feature and userspace can effectively stop the device. > > > > > > > > This is a must before get virtqueue indexes (base) for live migration, > > > > since the device could modify them after userland gets them. There are > > > > individual ways to perform that action for some devices > > > > (VHOST_NET_SET_BACKEND, VHOST_VSOCK_SET_RUNNING, ...) but there > > was no > > > > way to perform it for any vhost device (and, in particular, vhost-vdpa). > > > > > > > > After the return of ioctl with stop != 0, the device MUST finish any > > > > pending operations like in flight requests. It must also preserve all > > > > the necessary state (the virtqueue vring base plus the possible device > > > > specific states) that is required for restoring in the future. The > > > > device must not change its configuration after that point. > > > > > > > > After the return of ioctl with stop == 0, the device can continue > > > > processing buffers as long as typical conditions are met (vq is enabled, > > > > DRIVER_OK status bit is enabled, etc). > > Just to be clear, we are adding vdpa level new ioctl() that doesn’t map to any mechanism in the virtio spec. We try to provide forward compatibility to VIRTIO_CONFIG_S_STOP. That means it is expected to implement at least a subset of VIRTIO_CONFIG_S_STOP. > > Why can't we use this ioctl() to indicate driver to start/stop the device instead of driving it through the driver_ok? So the idea is to add capability that does not exist in the spec. Then came the stop/resume which can't be done via DRIVER_OK. I think we should only allow the stop/resume to succeed after DRIVER_OK is set. > This is in the context of other discussion we had in the LM series. Do you see any issue that blocks the live migration? Thanks
