[PATCH v5 00/20] vdpa net devices Rx filter change notification with Shadow VQ

Eugenio Pérez posted 20 patches 1 year, 9 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20220719095629.3031338-1-eperezma@redhat.com
Maintainers: "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>, Eric Blake <eblake@redhat.com>, Markus Armbruster <armbru@redhat.com>
There is a newer version of this series
qapi/net.json                      |   9 +-
hw/virtio/vhost-shadow-virtqueue.h |  52 ++++-
include/hw/virtio/vhost-vdpa.h     |   8 +
include/hw/virtio/virtio-net.h     |   7 +
hw/net/virtio-net.c                |  85 ++++---
hw/virtio/vhost-shadow-virtqueue.c | 210 ++++++++++++-----
hw/virtio/vhost-vdpa.c             |  26 ++-
net/vhost-vdpa.c                   | 357 +++++++++++++++++++++++++++--
8 files changed, 635 insertions(+), 119 deletions(-)
[PATCH v5 00/20] vdpa net devices Rx filter change notification with Shadow VQ
Posted by Eugenio Pérez 1 year, 9 months ago
Control virtqueue is used by networking device for accepting various
commands from the driver. It's a must to support advanced configurations.

Rx filtering event is issues by qemu when device's MAC address changed once and
the previous one has not been queried by external agents.

Shadow VirtQueue (SVQ) already makes possible tracking the state of virtqueues,
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.

This series uses SVQ infrastructure to intercept networking control messages
used by the device. This way, qemu is able to update VirtIONet device model and
react to them. In particular, this series enables rx filter change
notification.

This is a prerequisite to achieve net vdpa device with CVQ live migration.
It's a stripped down version of [1], with error paths checked and no migration
enabled.

First ten patches reorder and clean code base so its easier to apply later
ones. No functional change should be noticed from these changes.

Patches from 11 to 15 enable SVQ API to make other parts of qemu to interact
with it. In particular, they will be used by vhost-vdpa net to handle CVQ
messages.

Patches 16 to 18 enable the update of the virtio-net device model for each
CVQ message acknowledged by the device.

Last patches enable x-svq parameter, forbidding device migration since it is
not restored in the destination's vdpa device yet. This will be added in later
series, using this work.

They could conflict trivially with series [2].

Comments are welcome.
v5:
- Add a volatile access modifier to force compiler to emit the read instruction
- Fix use of undefined variable

v4:
- Add a timeout to vhost_svq_poll to not hold BQL forever

v3:
- Replace SVQElement with SVQDescState

v2:
- (Comments from series [1]).
- Active poll for CVQ answer instead of relay on async used callback
- Do not offer a new buffer to device but reuse qemu's
- Use vhost_svq_add instead of not needed vhost_svq_inject
- Delete used and detach callbacks, not needed anymore
- Embed members of SVQElement in VirtQueueElement
- Reuse the same buffers for all CVQ commands

[1] https://patchwork.kernel.org/project/qemu-devel/cover/20220706184008.1649478-1-eperezma@redhat.com/
[2] https://lists.nongnu.org/archive/html/qemu-devel/2022-07/msg02984.html

Eugenio Pérez (20):
  vhost: move descriptor translation to vhost_svq_vring_write_descs
  virtio-net: Expose MAC_TABLE_ENTRIES
  virtio-net: Expose ctrl virtqueue logic
  vdpa: Avoid compiler to squash reads to used idx
  vhost: Reorder vhost_svq_kick
  vhost: Move vhost_svq_kick call to vhost_svq_add
  vhost: Check for queue full at vhost_svq_add
  vhost: Decouple vhost_svq_add from VirtQueueElement
  vhost: Add SVQDescState
  vhost: Track number of descs in SVQDescState
  vhost: add vhost_svq_push_elem
  vhost: Expose vhost_svq_add
  vhost: add vhost_svq_poll
  vhost: Add svq avail_handler callback
  vdpa: Export vhost_vdpa_dma_map and unmap calls
  vdpa: manual forward CVQ buffers
  vdpa: Buffer CVQ support on shadow virtqueue
  vdpa: Extract get features part from vhost_vdpa_get_max_queue_pairs
  vdpa: Add device migration blocker
  vdpa: Add x-svq to NetdevVhostVDPAOptions

 qapi/net.json                      |   9 +-
 hw/virtio/vhost-shadow-virtqueue.h |  52 ++++-
 include/hw/virtio/vhost-vdpa.h     |   8 +
 include/hw/virtio/virtio-net.h     |   7 +
 hw/net/virtio-net.c                |  85 ++++---
 hw/virtio/vhost-shadow-virtqueue.c | 210 ++++++++++++-----
 hw/virtio/vhost-vdpa.c             |  26 ++-
 net/vhost-vdpa.c                   | 357 +++++++++++++++++++++++++++--
 8 files changed, 635 insertions(+), 119 deletions(-)

-- 
2.31.1

Re: [PATCH v5 00/20] vdpa net devices Rx filter change notification with Shadow VQ
Posted by Eugenio Perez Martin 1 year, 9 months ago
On Tue, Jul 19, 2022 at 12:01 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 advanced configurations.
>
> Rx filtering event is issues by qemu when device's MAC address changed once and
> the previous one has not been queried by external agents.
>
> Shadow VirtQueue (SVQ) already makes possible tracking the state of virtqueues,
> 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.
>
> This series uses SVQ infrastructure to intercept networking control messages
> used by the device. This way, qemu is able to update VirtIONet device model and
> react to them. In particular, this series enables rx filter change
> notification.
>
> This is a prerequisite to achieve net vdpa device with CVQ live migration.
> It's a stripped down version of [1], with error paths checked and no migration
> enabled.
>
> First ten patches reorder and clean code base so its easier to apply later
> ones. No functional change should be noticed from these changes.
>
> Patches from 11 to 15 enable SVQ API to make other parts of qemu to interact
> with it. In particular, they will be used by vhost-vdpa net to handle CVQ
> messages.
>
> Patches 16 to 18 enable the update of the virtio-net device model for each
> CVQ message acknowledged by the device.
>
> Last patches enable x-svq parameter, forbidding device migration since it is
> not restored in the destination's vdpa device yet. This will be added in later
> series, using this work.
>

As a suggestion, maybe it is better to omit patches 18 to 20 if we
don't merge the CVQ start code, same as with SVQ base. Part of the
code is meant to be reverted (migration blocker, actual x-svq
parameter), we can develop start and ASID code on top of 01-17.

Thanks!