All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.