From: "Eugenio Pérez" <eperezma@redhat.com>
To: "Michael S . Tsirkin" <mst@redhat.com>
Cc: "Cindy Lu" <lulu@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Jason Wang" <jasowang@redhat.com>,
linux-kernel@vger.kernel.org,
"Maxime Coquelin" <mcoqueli@redhat.com>,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
"Yongji Xie" <xieyongji@bytedance.com>,
virtualization@lists.linux.dev
Subject: [PATCH v3 0/3] Add queue ready message to VDUSE
Date: Tue, 10 Mar 2026 20:07:56 +0100 [thread overview]
Message-ID: <20260310190759.1097506-1-eperezma@redhat.com> (raw)
This series introduces a new VDUSE message for VDUSE userland instance
to detect when a VirtQueue (VQ) is enabled, replacing the polling.
VirtIO net devices' dataplane is started after the control virtqueue so
QEMU can apply the configuration in the destination of a Live Migration.
Without this feature, the VDUSE instance must poll the VQs to check when
(and if) a VQ has been enabled.
This series also implements VDUSE feature flags allowing the VDUSE
devices to opt-in to the VQ ready message. Devices that opt-in to this
feature will receive explicit notifications when a VQ is ready. Devices
that do not set this flag remain unaffected, ensuring backward
compatibility without indefinitely incrementing API versions.
The VDUSE features is a 64 bit bitmap for simplicity, the same way as
vhost and vhost-net started. It can be extended as a flexible array of
bits when we reach so many features, but it seems unlikely at this
point.
Error cases tested:
* Call VDUSE_GET_FEATURES without get the API VERSION (so API == 0) and
with API VERSION set to 1 with VDUSE_SET_API_VERSION (-EINVAL returned
from VDUSE_GET_FEATURES ioctl).
* Try to create a device with config->features different than 0 without
fetch the api version (so API == 0) and with API_VERSION set to 1
(-EINVAL returned from VDUSE_CREATE_DEV ioctl).
* Test regular initialization of single queue devices with V2 with and
without VDUSE_F_QUEUE_READY set in device->config.
* Test expected behavior when VDUSE userland instance returns
VDUSE_REQ_RESULT_FAILED from VDUSE_SET_VQ_READY message.
* Repeat all the tests with multiqueue devices, by reverting
56e71885b0349 ("vduse: Temporarily fail if control queue feature requested").
This series depends on
https://lore.kernel.org/lkml/20260119143306.1818855-1-eperezma@redhat.com/
v3:
* Remove API_VERSION bump to 2
* Add comment about struct vduse_dev_config:vduse_features is only valid
if VDUSE_GET_FEATURES success.
v2:
* Fix comment of vduse_dev_request.vq_ready
* Set vq_ready before sending the message to the VDUSE userland
instance, avoiding the need for SMP sync after receiving the message.
* Return -EINVAL if control ioctl called with version < 2, so userland
visible reply is kept (Jason).
Eugenio Pérez (3):
vduse: store control device pointer
vduse: add VDUSE_GET_FEATURES ioctl
vduse: add F_QUEUE_READY feature
drivers/vdpa/vdpa_user/vduse_dev.c | 41 +++++++++++++++++++++++++++---
include/uapi/linux/vduse.h | 25 +++++++++++++++++-
2 files changed, 61 insertions(+), 5 deletions(-)
--
2.53.0
next reply other threads:[~2026-03-10 19:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 19:07 Eugenio Pérez [this message]
2026-03-10 19:07 ` [PATCH v3 1/3] vduse: store control device pointer Eugenio Pérez
2026-03-10 19:07 ` [PATCH v3 2/3] vduse: add VDUSE_GET_FEATURES ioctl Eugenio Pérez
2026-03-12 3:55 ` Jason Wang
2026-03-12 7:11 ` Eugenio Perez Martin
2026-03-13 5:56 ` Jason Wang
2026-03-13 6:46 ` Eugenio Perez Martin
2026-03-10 19:07 ` [PATCH v3 3/3] vduse: add F_QUEUE_READY feature Eugenio Pérez
2026-03-12 3:58 ` Jason Wang
2026-03-12 6:24 ` Eugenio Perez Martin
2026-03-13 6:04 ` Jason Wang
2026-03-13 7:08 ` Eugenio Perez Martin
2026-03-24 14:01 ` Eugenio Perez Martin
2026-03-24 15:24 ` Michael S. Tsirkin
2026-03-26 2:44 ` Jason Wang
2026-03-26 6:56 ` Eugenio Perez Martin
2026-03-27 1:15 ` Jason Wang
2026-03-27 6:24 ` Eugenio Perez Martin
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=20260310190759.1097506-1-eperezma@redhat.com \
--to=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=lvivier@redhat.com \
--cc=mcoqueli@redhat.com \
--cc=mst@redhat.com \
--cc=sgarzare@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xieyongji@bytedance.com \
--cc=xuanzhuo@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.