Re: [RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK

2023-01-17 Thread Maxime Coquelin
Hi Eugenio, On 1/13/23 11:03, Eugenio Perez Martin wrote: On Fri, Jan 13, 2023 at 10:51 AM Stefano Garzarella wrote: On Fri, Jan 13, 2023 at 09:19:00AM +0100, Eugenio Perez Martin wrote: On Fri, Jan 13, 2023 at 5:36 AM Jason Wang wrote: On Fri, Jan 13, 2023 at 1:25 AM Eugenio Pérez

Re: [RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK

2023-01-16 Thread Jason Wang
在 2023/1/17 00:16, Eugenio Perez Martin 写道: On Mon, Jan 16, 2023 at 7:37 AM Jason Wang wrote: 在 2023/1/13 16:19, Eugenio Perez Martin 写道: On Fri, Jan 13, 2023 at 5:36 AM Jason Wang wrote: On Fri, Jan 13, 2023 at 1:25 AM Eugenio Pérez wrote: To restore the device at the destination of a

Re: [RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK

2023-01-16 Thread Eugenio Perez Martin
On Mon, Jan 16, 2023 at 7:37 AM Jason Wang wrote: > > > 在 2023/1/13 16:19, Eugenio Perez Martin 写道: > > On Fri, Jan 13, 2023 at 5:36 AM Jason Wang wrote: > >> On Fri, Jan 13, 2023 at 1:25 AM Eugenio Pérez wrote: > >>> To restore the device at the destination of a live migration we send the >

Re: [RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK

2023-01-15 Thread Jason Wang
在 2023/1/13 16:19, Eugenio Perez Martin 写道: On Fri, Jan 13, 2023 at 5:36 AM Jason Wang wrote: On Fri, Jan 13, 2023 at 1:25 AM Eugenio Pérez wrote: To restore the device at the destination of a live migration we send the commands through control virtqueue. For a device to read CVQ it must

Re: [RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK

2023-01-13 Thread Stefano Garzarella
On Fri, Jan 13, 2023 at 11:03:17AM +0100, Eugenio Perez Martin wrote: On Fri, Jan 13, 2023 at 10:51 AM Stefano Garzarella wrote: On Fri, Jan 13, 2023 at 09:19:00AM +0100, Eugenio Perez Martin wrote: >On Fri, Jan 13, 2023 at 5:36 AM Jason Wang wrote: >> >> On Fri, Jan 13, 2023 at 1:25 AM

Re: [RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK

2023-01-13 Thread Eugenio Perez Martin
On Fri, Jan 13, 2023 at 10:51 AM Stefano Garzarella wrote: > > On Fri, Jan 13, 2023 at 09:19:00AM +0100, Eugenio Perez Martin wrote: > >On Fri, Jan 13, 2023 at 5:36 AM Jason Wang wrote: > >> > >> On Fri, Jan 13, 2023 at 1:25 AM Eugenio Pérez wrote: > >> > > >> > To restore the device at the

Re: [RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK

2023-01-13 Thread Stefano Garzarella
On Fri, Jan 13, 2023 at 09:19:00AM +0100, Eugenio Perez Martin wrote: On Fri, Jan 13, 2023 at 5:36 AM Jason Wang wrote: On Fri, Jan 13, 2023 at 1:25 AM Eugenio Pérez wrote: > > To restore the device at the destination of a live migration we send the > commands through control virtqueue. For

Re: [RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK

2023-01-13 Thread Eugenio Perez Martin
On Fri, Jan 13, 2023 at 5:36 AM Jason Wang wrote: > > On Fri, Jan 13, 2023 at 1:25 AM Eugenio Pérez wrote: > > > > To restore the device at the destination of a live migration we send the > > commands through control virtqueue. For a device to read CVQ it must > > have received the DRIVER_OK

Re: [RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK

2023-01-12 Thread Jason Wang
On Fri, Jan 13, 2023 at 1:25 AM Eugenio Pérez wrote: > > To restore the device at the destination of a live migration we send the > commands through control virtqueue. For a device to read CVQ it must > have received the DRIVER_OK status bit. This probably requires the support from the parent

[RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK

2023-01-12 Thread Eugenio Pérez
To restore the device at the destination of a live migration we send the commands through control virtqueue. For a device to read CVQ it must have received the DRIVER_OK status bit. However this opens a window where the device could start receiving packets in rx queue 0 before it receives the RSS