linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dragos Tatulea <dtatulea@nvidia.com>
To: "Michael S . Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Eugenio Perez Martin <eperezma@redhat.com>,
	Si-Wei Liu <si-wei.liu@oracle.com>,
	Saeed Mahameed <saeedm@nvidia.com>,
	Leon Romanovsky <leon@kernel.org>,
	<virtualization@lists.linux-foundation.org>
Cc: Dragos Tatulea <dtatulea@nvidia.com>, <kvm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, Parav Pandit <parav@nvidia.com>,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: [PATCH vhost v4 02/16] vdpa: introduce dedicated descriptor group for virtqueue
Date: Wed, 18 Oct 2023 20:14:41 +0300	[thread overview]
Message-ID: <20231018171456.1624030-4-dtatulea@nvidia.com> (raw)
In-Reply-To: <20231018171456.1624030-2-dtatulea@nvidia.com>

From: Si-Wei Liu <si-wei.liu@oracle.com>

In some cases, the access to the virtqueue's descriptor area, device
and driver areas (precluding indirect descriptor table in guest memory)
may have to be confined to a different address space than where its
buffers reside. Without loss of simplicity and generality with already
established terminology, let's fold up these 3 areas and call them
as a whole as descriptor table group, or descriptor group for short.
Specifically, in case of split virtqueues, descriptor group consists of
regions for Descriptor Table, Available Ring and Used Ring; for packed
virtqueues layout, descriptor group contains Descriptor Ring, Driver
and Device Event Suppression structures.

The group ID for a dedicated descriptor group can be obtained through a
new .get_vq_desc_group() op. If driver implements this op, it means that
the descriptor, device and driver areas of the virtqueue may reside
in a dedicated group than where its buffers reside, a.k.a the default
virtqueue group through the .get_vq_group() op.

In principle, the descriptor group may or may not have same group ID
as the default group. Even if the descriptor group has a different ID,
meaning the vq's descriptor group areas can optionally move to a
separate address space than where guest memory resides, the descriptor
group may still start from a default address space, same as where its
buffers reside. To move the descriptor group to a different address
space, .set_group_asid() has to be called to change the ASID binding
for the group, which is no different than what needs to be done on any
other virtqueue group. On the other hand, the .reset() semantics also
applies on descriptor table group, meaning the device reset will clear
all ASID bindings and move all virtqueue groups including descriptor
group back to the default address space, i.e. in ASID 0.

QEMU's shadow virtqueue is going to utilize dedicated descriptor group
to speed up map and unmap operations, yielding tremendous downtime
reduction by avoiding the full and slow remap cycle in SVQ switching.

Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
 include/linux/vdpa.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 0e652026b776..d376309b99cf 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -204,6 +204,16 @@ struct vdpa_map_file {
  *				@vdev: vdpa device
  *				@idx: virtqueue index
  *				Returns u32: group id for this virtqueue
+ * @get_vq_desc_group:		Get the group id for the descriptor table of
+ *				a specific virtqueue (optional)
+ *				@vdev: vdpa device
+ *				@idx: virtqueue index
+ *				Returns u32: group id for the descriptor table
+ *				portion of this virtqueue. Could be different
+ *				than the one from @get_vq_group, in which case
+ *				the access to the descriptor table can be
+ *				confined to a separate asid, isolating from
+ *				the virtqueue's buffer address access.
  * @get_device_features:	Get virtio features supported by the device
  *				@vdev: vdpa device
  *				Returns the virtio features support by the
@@ -360,6 +370,7 @@ struct vdpa_config_ops {
 	/* Device ops */
 	u32 (*get_vq_align)(struct vdpa_device *vdev);
 	u32 (*get_vq_group)(struct vdpa_device *vdev, u16 idx);
+	u32 (*get_vq_desc_group)(struct vdpa_device *vdev, u16 idx);
 	u64 (*get_device_features)(struct vdpa_device *vdev);
 	u64 (*get_backend_features)(const struct vdpa_device *vdev);
 	int (*set_driver_features)(struct vdpa_device *vdev, u64 features);
-- 
2.41.0


  parent reply	other threads:[~2023-10-18 17:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 17:14 [PATCH vhost v4 00/16] vdpa: Add support for vq descriptor mappings Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 01/16] vdpa/mlx5: Expose descriptor group mkey hw capability Dragos Tatulea
2023-10-18 17:14 ` Dragos Tatulea [this message]
2023-10-18 17:14 ` [PATCH vhost v4 03/16] vhost-vdpa: introduce descriptor group backend feature Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 04/16] vhost-vdpa: uAPI to get dedicated descriptor group id Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 05/16] vdpa/mlx5: Create helper function for dma mappings Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 06/16] vdpa/mlx5: Decouple cvq iotlb handling from hw mapping code Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 07/16] vdpa/mlx5: Take cvq iotlb lock during refresh Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 08/16] vdpa/mlx5: Collapse "dvq" mr add/delete functions Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 09/16] vdpa/mlx5: Rename mr destroy functions Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 10/16] vdpa/mlx5: Allow creation/deletion of any given mr struct Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 11/16] vdpa/mlx5: Move mr mutex out of " Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 12/16] vdpa/mlx5: Improve mr update flow Dragos Tatulea
2023-10-18 17:21   ` Dragos Tatulea
2023-10-20 16:01     ` Eugenio Perez Martin
2023-10-23  8:07       ` Dragos Tatulea
2023-10-24 14:50         ` Eugenio Perez Martin
2023-10-18 17:14 ` [PATCH vhost v4 13/16] vdpa/mlx5: Introduce mr for vq descriptor Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 14/16] vdpa/mlx5: Enable hw support for vq descriptor mapping Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 15/16] vdpa/mlx5: Make iotlb helper functions more generic Dragos Tatulea
2023-10-18 17:14 ` [PATCH vhost v4 16/16] vdpa/mlx5: Update cvq iotlb mapping on ASID change Dragos Tatulea
2023-10-18 17:24 ` [PATCH vhost v4 00/16] vdpa: Add support for vq descriptor mappings Michael S. Tsirkin
2023-10-19 23:47 ` Si-Wei Liu
2023-10-24  6:45   ` Lei Yang

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=20231018171456.1624030-4-dtatulea@nvidia.com \
    --to=dtatulea@nvidia.com \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=parav@nvidia.com \
    --cc=saeedm@nvidia.com \
    --cc=si-wei.liu@oracle.com \
    --cc=virtualization@lists.linux-foundation.org \
    --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;
as well as URLs for NNTP newsgroup(s).