On Sat, Jul 29, 2023 at 1:20 AM Eugenio Pérez <epere...@redhat.com> wrote:
>
> At this moment the migration of net features that depends on CVQ is not
> possible, as there is no reliable way to restore the device state like mac
> address, number of enabled queues, etc to the destination. This is mainly
> caused because the device must only read CVQ, and process all the commands
> before resuming the dataplane.
>
> This series lift that requirement, sending the VHOST_VDPA_SET_VRING_ENABLE
> ioctl for dataplane vqs only after the device has processed all commands.
I think it's better to explain (that is what I don't understand) why
we can not simply reorder vhost_net_start_one() in vhost_net_start()?
for (i = 0; i < nvhosts; i++) {
if (i < data_queue_pairs) {
peer = qemu_get_peer(ncs, i);
} else {
peer = qemu_get_peer(ncs, n->max_queue_pairs);
}
if (peer->vring_enable) {
/* restore vring enable state */
r = vhost_set_vring_enable(peer, peer->vring_enable);
if (r < 0) {
goto err_start;
}
}
=> r = vhost_net_start_one(get_vhost_net(peer), dev);
if (r < 0) {
goto err_start;
}
}
Can we simply start cvq first here?
Thanks
> ---
> From FRC:
> * Enable vqs early in case CVQ cannot be shadowed.
>
> Eugenio Pérez (7):
> vdpa: export vhost_vdpa_set_vring_ready
> vdpa: add should_enable op
> vdpa: use virtio_ops->should_enable at vhost_vdpa_set_vrings_ready
> vdpa: add stub vhost_vdpa_should_enable
> vdpa: delay enable of data vqs
> vdpa: enable cvq svq if data vq are shadowed
> vdpa: remove net cvq migration blocker
>
> include/hw/virtio/vhost-vdpa.h | 9 +++++
> hw/virtio/vhost-vdpa.c | 33 ++++++++++++----
> net/vhost-vdpa.c | 69 ++++++++++++++++++++++++++--------
> hw/virtio/trace-events | 2 +-
> 4 files changed, 89 insertions(+), 24 deletions(-)
>
> --
> 2.39.3
>
>
