qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 00/19] vdpa net devices Rx filter change notification with


From: Jason Wang
Subject: Re: [PATCH v3 00/19] vdpa net devices Rx filter change notification with Shadow VQ
Date: Mon, 18 Jul 2022 11:32:57 +0800

On Sat, Jul 16, 2022 at 1:18 AM 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 nine 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 14 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 15 to 17 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.
>
> Comments are welcome.
> 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] 
> 20220706184008.1649478-1-eperezma@redhat.com/">https://patchwork.kernel.org/project/qemu-devel/cover/20220706184008.1649478-1-eperezma@redhat.com/
>
> Eugenio Pérez (19):
>   vhost: move descriptor translation to vhost_svq_vring_write_descs
>   virtio-net: Expose MAC_TABLE_ENTRIES
>   virtio-net: Expose ctrl virtqueue logic
>   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 | 202 +++++++++++-----
>  hw/virtio/vhost-vdpa.c             |  25 +-
>  net/vhost-vdpa.c                   | 357 +++++++++++++++++++++++++++--
>  8 files changed, 627 insertions(+), 118 deletions(-)

Looks good to me.

Michael, if you don't object, I plan to merge this series so vendors
can start to test this.

Thanks

>
> --
> 2.31.1
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]