[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 00/20] vdpa net devices Rx filter change notification with
From: |
Eugenio Perez Martin |
Subject: |
Re: [PATCH v5 00/20] vdpa net devices Rx filter change notification with Shadow VQ |
Date: |
Tue, 19 Jul 2022 12:04:34 +0200 |
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!
- [PATCH v5 11/20] vhost: add vhost_svq_push_elem, (continued)
- [PATCH v5 11/20] vhost: add vhost_svq_push_elem, Eugenio Pérez, 2022/07/19
- [PATCH v5 10/20] vhost: Track number of descs in SVQDescState, Eugenio Pérez, 2022/07/19
- [PATCH v5 13/20] vhost: add vhost_svq_poll, Eugenio Pérez, 2022/07/19
- [PATCH v5 16/20] vdpa: manual forward CVQ buffers, Eugenio Pérez, 2022/07/19
- [PATCH v5 15/20] vdpa: Export vhost_vdpa_dma_map and unmap calls, Eugenio Pérez, 2022/07/19
- [PATCH v5 14/20] vhost: Add svq avail_handler callback, Eugenio Pérez, 2022/07/19
- [PATCH v5 17/20] vdpa: Buffer CVQ support on shadow virtqueue, Eugenio Pérez, 2022/07/19
- [PATCH v5 18/20] vdpa: Extract get features part from vhost_vdpa_get_max_queue_pairs, Eugenio Pérez, 2022/07/19
- [PATCH v5 19/20] vdpa: Add device migration blocker, Eugenio Pérez, 2022/07/19
- [PATCH v5 20/20] vdpa: Add x-svq to NetdevVhostVDPAOptions, Eugenio Pérez, 2022/07/19
- Re: [PATCH v5 00/20] vdpa net devices Rx filter change notification with Shadow VQ,
Eugenio Perez Martin <=