From: "Eugenio Pérez" <eperezma@redhat.com>
To: "Michael S . Tsirkin" <mst@redhat.com>
Cc: "Eugenio Pérez" <eperezma@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
"Yongji Xie" <xieyongji@bytedance.com>,
linux-kernel@vger.kernel.org,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Jason Wang" <jasowangio@gmail.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
virtualization@lists.linux.dev,
"Maxime Coquelin" <mcoqueli@redhat.com>
Subject: [PATCH v4 0/4] Add queue ready message to VDUSE
Date: Tue, 7 Jul 2026 14:24:58 +0200 [thread overview]
Message-ID: <20260707122502.239022-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 set invalid features.
* Test regular initialization of single queue devices with and without
VDUSE_F_QUEUE_READY set.
* 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").
v4:
* Create its own spinlock for vq->ready instead of relying on kick and
call spinlocks.
* Add VDUSE_SET_FEATURES ioctl and the corresponding validation paths instead
of using device config.
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 (4):
vduse: store control device pointer
vduse: add VDUSE_GET_FEATURES ioctl
vduse: add VDUSE_SET_FEATURES ioctl
vduse: add F_QUEUE_READY feature
drivers/vdpa/vdpa_user/vduse_dev.c | 111 +++++++++++++++++++++++------
include/uapi/linux/vduse.h | 24 +++++++
2 files changed, 115 insertions(+), 20 deletions(-)
--
2.55.0
next reply other threads:[~2026-07-07 12:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 12:24 Eugenio Pérez [this message]
2026-07-07 12:24 ` [PATCH v4 1/4] vduse: store control device pointer Eugenio Pérez
2026-07-07 12:25 ` [PATCH v4 2/4] vduse: add VDUSE_GET_FEATURES ioctl Eugenio Pérez
2026-07-07 12:25 ` [PATCH v4 3/4] vduse: add VDUSE_SET_FEATURES ioctl Eugenio Pérez
2026-07-07 12:25 ` [PATCH v4 4/4] vduse: add F_QUEUE_READY feature Eugenio Pérez
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=20260707122502.239022-1-eperezma@redhat.com \
--to=eperezma@redhat.com \
--cc=jasowangio@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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.