From: Stephen Hemminger <stephen@networkplumber.org>
To: "Eugenio Pérez" <eperezma@redhat.com>
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>,
chenbox@nvidia.com, jasowang@redhat.com,
david.marchand@redhat.com, dev@dpdk.org,
Yongji Xie <xieyongji@bytedance.com>,
mst@redhat.com
Subject: Re: [RFC v3 00/10] Add vduse live migration features
Date: Sun, 29 Mar 2026 11:14:44 -0700 [thread overview]
Message-ID: <20260329111444.01e857b4@phoenix.local> (raw)
In-Reply-To: <20260311065543.1354037-1-eperezma@redhat.com>
On Wed, 11 Mar 2026 07:55:33 +0100
Eugenio Pérez <eperezma@redhat.com> wrote:
> This series introduces features to the VDUSE (vDPA Device in Userspace) driver
> to support Live Migration.
>
> Currently, DPDK does not support VDUSE devices live migration because the
> driver lacks a mechanism to suspend the device and quiesce the rings to
> initiate the switchover. This series implements the suspend operation to
> address this limitation.
>
> Furthermore, enabling Live Migration for devices with control virtqueue needs
> two additional features. Both of them are included in this series.
>
> * Address Spaces (ASID) support: This allows QEMU to isolate and intercept the
> device's CVQ. By doing so, QEMU is able to migrate the device status
> transparently, without requiring the device to support state save and
> restore.
> * QUEUE_ENABLE: This allows QEMU to control when the dataplane virtqueues are
> enabled. This ensures the dataplane is started after the device
> configuration has been fully restores via the CVQ.
>
> Last but not least, it enables the VIRTIO_NET_F_STATUS feature. This allows the
> device to signal the driver that it needs to send gratuitous ARP with
> VIRTIO_NET_S_ANNOUNCE, reducing the Live Migration downtime.
>
> v3:
> * Replace incorrect '%lx' DEBUG print format specifier with PRIx64
>
> v2:
> * Following latest comments on kernel series about VDUSE features, not checking
> API version but only check if VDUSE_GET_FEATURES success.
> * Move the start and last declarations in the braces as gcc 8 does not like
> them interleaved with statements. Actually, I think the move was a mistake in
> the first version.
> https://mails.dpdk.org/archives/test-report/2026-February/958175.html
>
> Eugenio Pérez (1):
> uapi: align VDUSE header for ASID
>
> Maxime Coquelin (6):
> vhost: introduce ASID support
> vhost: add VDUSE API version negotiation
> vhost: add virtqueues groups support to VDUSE
> vhost: add ASID support to VDUSE IOTLB operations
> vhost: claim VDUSE support for API version 1
> vhost: add net status feature to VDUSE
>
> Super User (3):
> uapi: Align vduse.h for enable and suspend VDUSE messages
> vhost: Support VDUSE QUEUE_READY feature
> vhost: Support vduse suspend feature
>
> kernel/linux/uapi/linux/vduse.h | 114 +++++++++++++++-
> lib/vhost/iotlb.c | 226 ++++++++++++++++++++------------
> lib/vhost/iotlb.h | 14 +-
> lib/vhost/vduse.c | 197 +++++++++++++++++++++++++---
> lib/vhost/vduse.h | 3 +-
> lib/vhost/vhost.c | 16 +--
> lib/vhost/vhost.h | 16 +--
> lib/vhost/vhost_user.c | 11 +-
> 8 files changed, 460 insertions(+), 137 deletions(-)
>
As an experiment tried Google Gemini with AGENTS file to review this patch.
Summary of Findings
The patch series successfully introduces ASID support and VDUSE API version 1 features (virtqueue groups, net status, queue
ready, and suspend) to the vhost library. However, there are a few correctness issues, most notably a resource leak in the
IOTLB initialization error path, and several style nits regarding pointer comparisons.
---
Correctness Bugs (High Priority)
1. Resource Leak in vhost_user_iotlb_init (lib/vhost/iotlb.c)
In Patch 02/10, the newly introduced vhost_user_iotlb_init function fails to correctly clean up resources when one of the
ASID IOTLB initializations fails.
1 +int
2 +vhost_user_iotlb_init(struct virtio_net *dev)
3 +{
4 + int i;
5 +
6 + for (i = 0; i < IOTLB_MAX_ASID; i++)
7 + if (vhost_user_iotlb_init_one(dev, i) < 0)
8 + goto fail;
9 +
10 + return 0;
11 +fail:
12 + while (i--)
13 + {
14 + rte_free(dev->iotlb[i]->pool);
15 + dev->iotlb[i]->pool = NULL;
16 + }
17 +
18 + return -1;
19 +}
Issues:
- Leak of iotlb structures: The loop only frees the pool member but does not rte_free(dev->iotlb[i]).
- Incomplete cleanup of the failed index: If vhost_user_iotlb_init_one(dev, i) fails after allocating dev->iotlb[i] but
before returning, the while (i--) loop will skip the current index i, leaking its resources entirely.
- Zero-index failure: if i=0 fails, the while(i--) loop will not execute at all, leaking all resources allocated for index
0.
Recommendation: The fail block should call vhost_user_iotlb_destroy(dev) or be rewritten to properly free both the pool and
the iotlb structure for all indices up to and including the one that failed.
2. Potential NULL Pointer Dereference in VDUSE_SUSPEND Handler (lib/vhost/vduse.c)
In Patch 10/10, the VDUSE_SUSPEND case in vduse_events_handler accesses dev->notify_ops without a NULL check, unlike the
VDUSE_SET_VQ_READY handler in Patch 09/10.
1 + case VDUSE_SUSPEND:
2 + ...
3 + for (i = 0; dev->notify_ops->vring_state_changed &&
4 + i < dev->nr_vring; i++) {
Issue: If dev->notify_ops is NULL, this will cause a segmentation fault. While DRIVER_OK is checked, it is safer and more
consistent to explicitly check dev->notify_ops before access.
---
Style and Process Compliance
3. Implicit Pointer Comparisons
The DPDK coding style (per AGENTS.md) requires explicit comparisons for pointers (e.g., if (p == NULL)). Several patches use
implicit comparisons (if (!p)).
Instances include:
- Patch 02/10: if (!dev->iotlb[asid]) and if (!dev->iotlb[asid]->pool) in vhost_user_iotlb_init_one.
- Patch 09/10: if (!dev->notify_ops || !dev->notify_ops->vring_state_changed) in VDUSE_SET_VQ_READY handler.
- Patch 09/10: if (!dev->notify_ops) in vduse_device_start.
4. Confusing Log Message in VDUSE_SET_VQ_READY (lib/vhost/vduse.c)
In Patch 09/10:
1 + VHOST_CONFIG_LOG(dev->ifname, ERR,
2 + "Unexpected ready message with feature %d",
3 + !!(dev->vduse_features &
4 + RTE_BIT64(VDUSE_F_QUEUE_READY)));
Since this is inside a !(dev->vduse_features & ...) block, it will always log "feature 0". It would be clearer to state that
the VDUSE_F_QUEUE_READY feature was not negotiated.
5. Non-inclusive Naming in vduse_iotlb_miss (lib/vhost/vduse.c)
Patch 02/10 and 05/10 modify vduse_iotlb_miss. While not introduced by this patch, the function uses the term miss, which is
generally acceptable but should be noted if a more descriptive term like iotlb_entry_fetch_failure is preferred in the
future. (Note: This is a minor observation and does not strictly violate the prohibited terminology list).
---
Additional Observations
- UAPI Headers: The alignment with upcoming Linux kernel VDUSE headers (ASID, groups, suspend) is correctly handled in
patches 01 and 08.
- Experimental Tags: New internal logic is correctly added without exposing new public APIs, so __rte_experimental tags
were not required for these changes.
- Static Linking: The use of supported_vduse_features as a static constant correctly avoids namespace pollution.
prev parent reply other threads:[~2026-03-29 18:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 6:55 [RFC v3 00/10] Add vduse live migration features Eugenio Pérez
2026-03-11 6:55 ` [RFC v3 01/10] uapi: align VDUSE header for ASID Eugenio Pérez
2026-03-11 6:55 ` [RFC v3 02/10] vhost: introduce ASID support Eugenio Pérez
2026-03-11 6:55 ` [RFC v3 03/10] vhost: add VDUSE API version negotiation Eugenio Pérez
2026-03-11 6:55 ` [RFC v3 04/10] vhost: add virtqueues groups support to VDUSE Eugenio Pérez
2026-03-11 6:55 ` [RFC v3 05/10] vhost: add ASID support to VDUSE IOTLB operations Eugenio Pérez
2026-03-11 6:55 ` [RFC v3 06/10] vhost: claim VDUSE support for API version 1 Eugenio Pérez
2026-03-11 6:55 ` [RFC v3 07/10] vhost: add net status feature to VDUSE Eugenio Pérez
2026-03-11 6:55 ` [RFC v3 08/10] uapi: Align vduse.h for enable and suspend VDUSE messages Eugenio Pérez
2026-03-11 6:55 ` [RFC v3 09/10] vhost: Support VDUSE QUEUE_READY feature Eugenio Pérez
2026-03-11 6:55 ` [RFC v3 10/10] vhost: Support vduse suspend feature Eugenio Pérez
2026-03-29 18:14 ` Stephen Hemminger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260329111444.01e857b4@phoenix.local \
--to=stephen@networkplumber.org \
--cc=chenbox@nvidia.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=xieyongji@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox