mirror of https://lore.kernel.org/lkml/
 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>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Yongji Xie" <xieyongji@bytedance.com>,
	"Stefano Garzarella" <sgarzare@redhat.com>,
	virtualization@lists.linux.dev,
	"Laurent Vivier" <lvivier@redhat.com>,
	linux-kernel@vger.kernel.org,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	jasowang@redhat.com, "Maxime Coquelin" <mcoqueli@redhat.com>
Subject: [RFC v2 0/7] Add multiple address spaces support to VDUSE
Date: Thu,  7 Aug 2025 13:57:45 +0200	[thread overview]
Message-ID: <20250807115752.1663383-1-eperezma@redhat.com> (raw)

When used by vhost-vDPA bus driver for VM, the control virtqueue
should be shadowed via userspace VMM (QEMU) instead of being assigned
directly to Guest. This is because QEMU needs to know the device state
in order to start and stop device correctly (e.g for Live Migration).

This requies to isolate the memory mapping for control virtqueue
presented by vhost-vDPA to prevent guest from accessing it directly.

This series add support to multiple address spaces in VDUSE device
allowing selective virtqueue isolation through address space IDs (ASID).

The VDUSE device needs to report:
* Number of virtqueue groups
* Association of each vq group with each virtqueue
* Number of address spaces supported.

Then, the vDPA driver can modify the ASID assigned to each VQ group to
isolate the memory AS.  This aligns VDUSE with gq}vdpa_sim and nvidia
mlx5 devices which already support ASID.

This helps to isolate the environments for the virtqueues that will not
be assigned directly. E.g in the case of virtio-net, the control
virtqueue will not be assigned directly to guest.

This is still a RFC as it depends on the series that reworks the virtio mapping
API:
https://lore.kernel.org/all/20250718091616.6140-1-jasowang@redhat.com/

As some changes has been requested to it, these will need to be applied here
too.

Also, to be able to test this patch, the user needs to manually revert
56e71885b034 ("vduse: Temporarily fail if control queue feature requested").

v2:
* Cache group information in kernel, as we need to provide the vq map
  tokens properly.
* Add descs vq group to optimize SVQ forwarding and support indirect
  descriptors out of the box.
* Make iotlb entry the last one of vduse_iotlb_entry_v2 so the first
  part of the struct is the same.
* Fixes detected testing with OVS+VDUSE.

Eugenio Pérez (7):
  vduse: add v1 API definition
  vduse: add vq group support
  vdpa: change get_vq_map_token type to void *(*cb)
  vduse: return internal vq group struct as map token
  vduse: add vq group asid support
  vduse: send update_iotlb_v2 message
  vduse: bump version number

 drivers/vdpa/mlx5/net/mlx5_vnet.c  |   2 +-
 drivers/vdpa/vdpa_user/vduse_dev.c | 389 +++++++++++++++++++++++------
 include/linux/vdpa.h               |   2 +-
 include/uapi/linux/vduse.h         |  64 ++++-
 4 files changed, 371 insertions(+), 86 deletions(-)

-- 
2.50.1


             reply	other threads:[~2025-08-07 11:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-07 11:57 Eugenio Pérez [this message]
2025-08-07 11:57 ` [RFC v2 1/7] vduse: add v1 API definition Eugenio Pérez
2025-08-07 11:57 ` [RFC v2 2/7] vduse: add vq group support Eugenio Pérez
2025-08-08  7:46   ` Maxime Coquelin
2025-08-11  3:09   ` Jason Wang
2025-08-11  9:51     ` Eugenio Perez Martin
2025-08-12  3:01       ` Jason Wang
2025-08-13 10:11         ` Eugenio Perez Martin
2025-08-14  3:42           ` Jason Wang
2025-08-07 11:57 ` [RFC v2 3/7] vdpa: change get_vq_map_token type to void *(*cb) Eugenio Pérez
2025-08-07 11:57 ` [RFC v2 4/7] vduse: return internal vq group struct as map token Eugenio Pérez
2025-08-11  3:11   ` Jason Wang
2025-08-11 11:03     ` Eugenio Perez Martin
2025-08-12  3:02       ` Jason Wang
2025-08-07 11:57 ` [RFC v2 5/7] vduse: add vq group asid support Eugenio Pérez
2025-08-08  7:45   ` Maxime Coquelin
2025-08-10  9:45     ` Eugenio Perez Martin
2025-08-11  3:21   ` Jason Wang
2025-08-11 11:19     ` Eugenio Perez Martin
2025-08-12  3:05       ` Jason Wang
2025-08-13 11:02       ` Eugenio Perez Martin
2025-08-07 11:57 ` [RFC v2 6/7] vduse: send update_iotlb_v2 message Eugenio Pérez
2025-08-11  3:24   ` Jason Wang
2025-08-07 11:57 ` [RFC v2 7/7] vduse: bump version number 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=20250807115752.1663383-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®