On Tue, May 31, 2022 at 1:40 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Mon, May 30, 2022 at 11:39:21AM +0800, Jason Wang wrote: > > On Fri, May 27, 2022 at 6:56 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > > > On Thu, May 26, 2022 at 12:54:32PM +0000, Parav Pandit 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. > > > > > > > > Why can't we use this ioctl() to indicate driver to start/stop the device instead of driving it through the driver_ok? > > > > This is in the context of other discussion we had in the LM series. > > > > > > If there's something in the spec that does this then let's use that. > > > > Actually, we try to propose a independent feature here: > > > > https://lists.oasis-open.org/archives/virtio-dev/202111/msg00020.html > > > > Does it make sense to you? > > > > Thanks > > But I thought the LM patches are trying to replace all that? I'm not sure, and actually I think they are orthogonal. We need a new state and the command to set the state could be transport specific or a virtqueue. As far as I know, most of the vendors have implemented this semantic. Thanks > > > > > Unfortunately the LM series seems to be stuck on moving > > > bits around with the admin virtqueue ... > > > > > > -- > > > MST > > > > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
