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: "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


             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.