[RFC PATCH 0/9] Net Control VQ support in vDPA SVQ

Eugenio Pérez posted 9 patches 3 years, 11 months ago
Failed in applying to current master (apply log)
hw/virtio/vhost-shadow-virtqueue.h |  25 +++-
include/hw/virtio/vhost-vdpa.h     |   2 +
include/hw/virtio/virtio-net.h     |   3 +
include/hw/virtio/virtio.h         |   1 +
hw/net/virtio-net.c                |  83 ++++++-----
hw/virtio/vhost-shadow-virtqueue.c | 217 +++++++++++++++++++++++------
hw/virtio/vhost-vdpa.c             |  22 ++-
hw/virtio/virtio.c                 |   2 +-
net/vhost-vdpa.c                   | 140 +++++++++++++++++--
9 files changed, 405 insertions(+), 90 deletions(-)
[RFC PATCH 0/9] Net Control VQ support in vDPA SVQ
Posted by Eugenio Pérez 3 years, 11 months ago
Control virtqueue is used by networking device for accepting various
commands from the driver. It's a must to support multiqueue and other
configurations.

Shadow VirtQueue (SVQ) [1] already makes possible migration of virtqueue
states, effectively intercepting them so qemu can track what regions of memory
are dirty because device action and needs migration. However, this does not
solve networking device state seen by the driver because CVQ messages, like
changes on MAC addresses from the driver.

To solve that, this series uses SVQ infraestructure proposed at SVQ [1] to
intercept networking control messages used by the device. This way, qemu is
able to update VirtIONet device model and to migrate it. This series needs to
be applied on top of [1].

Ideally, only the control VQ would be shadowed for all the run of qemu and the
rest of virtqueues would be passthrough unless it's migration time. However,
this requires the vDPA device to support address translations from more than
one address space, something that is not possible at the moment with the
current vhost-vDPA API. The API change has been proposed at [2], but use of it
is left for future series.

Sending this as a RFC so some details like error control is still not 100%
tested. Comments are welcomed on every aspect of the patch.

[1] https://lore.kernel.org/qemu-devel/20220121202733.404989-1-eperezma@redhat.com/
[2] https://lkml.org/lkml/2020/9/23/1243

Eugenio Pérez (9):
  virtio-net: Expose ctrl virtqueue logic
  vdpa: Extract get geatures part from vhost_vdpa_get_max_queue_pairs
  virtio: Make virtqueue_alloc_element non-static
  vhost: Add SVQElement
  vhost: Add custom used buffer callback
  vdpa: Add map/unmap operation callback to SVQ
  vhost: Add vhost_svq_inject
  vhost: Add vhost_svq_start_op
  vdpa: control virtqueue support on shadow virtqueue

 hw/virtio/vhost-shadow-virtqueue.h |  25 +++-
 include/hw/virtio/vhost-vdpa.h     |   2 +
 include/hw/virtio/virtio-net.h     |   3 +
 include/hw/virtio/virtio.h         |   1 +
 hw/net/virtio-net.c                |  83 ++++++-----
 hw/virtio/vhost-shadow-virtqueue.c | 217 +++++++++++++++++++++++------
 hw/virtio/vhost-vdpa.c             |  22 ++-
 hw/virtio/virtio.c                 |   2 +-
 net/vhost-vdpa.c                   | 140 +++++++++++++++++--
 9 files changed, 405 insertions(+), 90 deletions(-)

-- 
2.27.0



Re: [RFC PATCH 0/9] Net Control VQ support in vDPA SVQ
Posted by Eugenio Perez Martin 3 years, 11 months ago
On Mon, Feb 14, 2022 at 8:38 PM Eugenio Pérez <eperezma@redhat.com> wrote:
>
> Control virtqueue is used by networking device for accepting various
> commands from the driver. It's a must to support multiqueue and other
> configurations.
>
> Shadow VirtQueue (SVQ) [1] already makes possible migration of virtqueue
> states, effectively intercepting them so qemu can track what regions of memory
> are dirty because device action and needs migration. However, this does not
> solve networking device state seen by the driver because CVQ messages, like
> changes on MAC addresses from the driver.
>
> To solve that, this series uses SVQ infraestructure proposed at SVQ [1] to
> intercept networking control messages used by the device. This way, qemu is
> able to update VirtIONet device model and to migrate it. This series needs to
> be applied on top of [1].
>
> Ideally, only the control VQ would be shadowed for all the run of qemu and the
> rest of virtqueues would be passthrough unless it's migration time. However,
> this requires the vDPA device to support address translations from more than
> one address space, something that is not possible at the moment with the
> current vhost-vDPA API. The API change has been proposed at [2], but use of it
> is left for future series.
>
> Sending this as a RFC so some details like error control is still not 100%
> tested. Comments are welcomed on every aspect of the patch.
>
> [1] https://lore.kernel.org/qemu-devel/20220121202733.404989-1-eperezma@redhat.com/
> [2] https://lkml.org/lkml/2020/9/23/1243
>
> Eugenio Pérez (9):
>   virtio-net: Expose ctrl virtqueue logic
>   vdpa: Extract get geatures part from vhost_vdpa_get_max_queue_pairs
>   virtio: Make virtqueue_alloc_element non-static
>   vhost: Add SVQElement
>   vhost: Add custom used buffer callback
>   vdpa: Add map/unmap operation callback to SVQ
>   vhost: Add vhost_svq_inject
>   vhost: Add vhost_svq_start_op
>   vdpa: control virtqueue support on shadow virtqueue
>
>  hw/virtio/vhost-shadow-virtqueue.h |  25 +++-
>  include/hw/virtio/vhost-vdpa.h     |   2 +
>  include/hw/virtio/virtio-net.h     |   3 +
>  include/hw/virtio/virtio.h         |   1 +
>  hw/net/virtio-net.c                |  83 ++++++-----
>  hw/virtio/vhost-shadow-virtqueue.c | 217 +++++++++++++++++++++++------
>  hw/virtio/vhost-vdpa.c             |  22 ++-
>  hw/virtio/virtio.c                 |   2 +-
>  net/vhost-vdpa.c                   | 140 +++++++++++++++++--
>  9 files changed, 405 insertions(+), 90 deletions(-)
>

This series is available to test at [1].

Thanks!

[1] https://github.com/eugpermar/qemu/releases/tag/vdpa_sw_live_migration.d%2Fcvq-v1

> --
> 2.27.0
>
>
>