[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v9 03/23] vdpa: delay set_vring_ready after DRIVER_OK
From: |
Jason Wang |
Subject: |
Re: [RFC PATCH v9 03/23] vdpa: delay set_vring_ready after DRIVER_OK |
Date: |
Fri, 8 Jul 2022 17:06:33 +0800 |
On Thu, Jul 7, 2022 at 2:40 AM Eugenio Pérez <eperezma@redhat.com> wrote:
>
> To restore the device in the destination of a live migration we send the
> commands through control virtqueue. For a device to read CVQ it must
> have received DRIVER_OK status bit.
>
> However this open a window where the device could start receiving
> packets in rx queue 0 before it receive the RSS configuration. To avoid
> that, we will not send vring_enable until all configuration is used by
> the device.
>
> As a first step, reverse the DRIVER_OK and SET_VRING_ENABLE steps.
I wonder if it's better to delay this to the series that implements
migration since the shadow cvq doesn't depends on this?
>
> Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> ---
> hw/virtio/vhost-vdpa.c | 22 ++++++++++++++++------
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
> index 66f054a12c..2ee8009594 100644
> --- a/hw/virtio/vhost-vdpa.c
> +++ b/hw/virtio/vhost-vdpa.c
> @@ -728,13 +728,18 @@ static int vhost_vdpa_get_vq_index(struct vhost_dev
> *dev, int idx)
> return idx;
> }
>
> +/**
> + * Set ready all vring of the device
> + *
> + * @dev: Vhost device
> + */
> static int vhost_vdpa_set_vring_ready(struct vhost_dev *dev)
> {
> int i;
> trace_vhost_vdpa_set_vring_ready(dev);
> - for (i = 0; i < dev->nvqs; ++i) {
> + for (i = 0; i < dev->vq_index_end; ++i) {
> struct vhost_vring_state state = {
> - .index = dev->vq_index + i,
> + .index = i,
Looks like a cleanup or bugfix which deserves a separate patch?
> .num = 1,
> };
> vhost_vdpa_call(dev, VHOST_VDPA_SET_VRING_ENABLE, &state);
> @@ -1097,7 +1102,6 @@ static int vhost_vdpa_dev_start(struct vhost_dev *dev,
> bool started)
> if (unlikely(!ok)) {
> return -1;
> }
> - vhost_vdpa_set_vring_ready(dev);
> } else {
> ok = vhost_vdpa_svqs_stop(dev);
> if (unlikely(!ok)) {
> @@ -1111,16 +1115,22 @@ static int vhost_vdpa_dev_start(struct vhost_dev
> *dev, bool started)
> }
>
> if (started) {
> + int r;
> +
> memory_listener_register(&v->listener, &address_space_memory);
> - return vhost_vdpa_add_status(dev, VIRTIO_CONFIG_S_DRIVER_OK);
> + r = vhost_vdpa_add_status(dev, VIRTIO_CONFIG_S_DRIVER_OK);
> + if (unlikely(r)) {
> + return r;
> + }
> + vhost_vdpa_set_vring_ready(dev);
Interesting, does this mean we only enable the last two queues without
this patch?
Thanks
> } else {
> vhost_vdpa_reset_device(dev);
> vhost_vdpa_add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE |
> VIRTIO_CONFIG_S_DRIVER);
> memory_listener_unregister(&v->listener);
> -
> - return 0;
> }
> +
> + return 0;
> }
>
> static int vhost_vdpa_set_log_base(struct vhost_dev *dev, uint64_t base,
> --
> 2.31.1
>
- Re: [RFC PATCH v9 04/23] vhost: Get vring base from vq, not svq, (continued)
[RFC PATCH v9 06/23] virtio-net: Expose ctrl virtqueue logic, Eugenio Pérez, 2022/07/06
[RFC PATCH v9 02/23] vhost: move descriptor translation to vhost_svq_vring_write_descs, Eugenio Pérez, 2022/07/06
[RFC PATCH v9 07/23] vhost: add vhost_svq_push_elem, Eugenio Pérez, 2022/07/06
[RFC PATCH v9 08/23] vhost: Decouple vhost_svq_add_split from VirtQueueElement, Eugenio Pérez, 2022/07/06
[RFC PATCH v9 03/23] vdpa: delay set_vring_ready after DRIVER_OK, Eugenio Pérez, 2022/07/06
[RFC PATCH v9 11/23] vhost: Move last chain id to SVQ element, Eugenio Pérez, 2022/07/06
[RFC PATCH v9 09/23] vhost: Add SVQElement, Eugenio Pérez, 2022/07/06