From: Si-Wei Liu <si-wei.liu@oracle.com>
To: jasowang@redhat.com
Cc: eperezma@redhat.com, gal@nvidia.com,
linux-kernel@vger.kernel.org, mst@redhat.com,
si-wei.liu@oracle.com, virtualization@lists.linux-foundation.org,
xuanzhuo@linux.alibaba.com
Subject: [PATCH RFC 0/4] vdpa: decouple reset of iotlb mapping from device reset
Date: Mon, 14 Aug 2023 18:43:23 -0700 [thread overview]
Message-ID: <1692063807-5018-1-git-send-email-si-wei.liu@oracle.com> (raw)
In-Reply-To: <CACGkMEseKv8MzaF8uxVTjkaAm2xvei578g=rNVzogfPQRQPOhQ@mail.gmail.com>
In order to reduce needlessly high setup and teardown cost
of iotlb mapping during live migration, it's crucial to
decouple the vhost-vdpa iotlb abstraction from the virtio
device life cycle, i.e. iotlb mappings should be left
intact across virtio device reset [1]. For it to work, the
on-chip IOMMU parent device should implement a separate
.reset_map() operation callback to restore 1:1 DMA mapping
without having to resort to the .reset() callback, which
is mainly used to reset virtio specific device state.
This new .reset_map() callback will be invoked only when
the vhost-vdpa driver is to be removed and detached from
the vdpa bus, such that other vdpa bus drivers, e.g.
virtio-vdpa, can get back on 1:1 DMA mapping when they
are attached. For the context, those on-chip IOMMU parent
devices, create the 1:1 DMA mapping at vdpa device add,
and they would implicitly destroy the 1:1 mapping when
the first .set_map or .dma_map callback is invoked.
[1] Reducing vdpa migration downtime because of memory pin / maps
https://www.mail-archive.com/qemu-devel@nongnu.org/msg953755.html
---
Si-Wei Liu (4):
vdpa: introduce .reset_map operation callback
vdpa/mlx5: implement .reset_map driver op
vhost-vdpa: should restore 1:1 dma mapping before detaching driver
vhost-vdpa: introduce IOTLB_PERSIST backend feature bit
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 1 +
drivers/vdpa/mlx5/core/mr.c | 72 +++++++++++++++++++++-----------------
drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 +++++++---
drivers/vhost/vdpa.c | 33 ++++++++++++++++-
include/linux/vdpa.h | 7 ++++
include/uapi/linux/vhost_types.h | 2 ++
6 files changed, 95 insertions(+), 38 deletions(-)
--
1.8.3.1
next prev parent reply other threads:[~2023-08-15 1:46 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 17:12 [PATCH 0/2] vdpa/mlx5: Fixes for ASID handling Dragos Tatulea
2023-08-02 17:12 ` [PATCH 1/2] vdpa/mlx5: Fix mr->initialized semantics Dragos Tatulea
2023-08-03 8:03 ` Jason Wang
2023-08-03 11:40 ` Dragos Tatulea
2023-08-08 2:57 ` Jason Wang
2023-08-08 7:24 ` Dragos Tatulea
2023-08-09 1:42 ` Jason Wang
2023-08-14 14:15 ` Dragos Tatulea
2023-08-15 1:28 ` Jason Wang
2023-08-03 17:57 ` Si-Wei Liu
2023-08-08 3:00 ` Jason Wang
2023-08-08 22:58 ` Si-Wei Liu
2023-08-09 6:52 ` Jason Wang
2023-08-10 0:40 ` Si-Wei Liu
2023-08-10 3:10 ` Jason Wang
2023-08-10 22:20 ` Si-Wei Liu
2023-08-14 2:59 ` Jason Wang
2023-08-15 1:43 ` Si-Wei Liu [this message]
2023-08-15 1:43 ` [PATCH RFC 1/4] vdpa: introduce .reset_map operation callback Si-Wei Liu
2023-08-15 2:21 ` Jason Wang
2023-08-15 19:49 ` Si-Wei Liu
2023-08-16 1:55 ` Jason Wang
2023-08-17 0:05 ` Si-Wei Liu
2023-08-17 15:28 ` Eugenio Perez Martin
2023-08-21 22:31 ` Si-Wei Liu
2023-08-15 1:43 ` [PATCH RFC 2/4] vdpa/mlx5: implement .reset_map driver op Si-Wei Liu
2023-08-15 8:26 ` Dragos Tatulea
2023-08-15 23:11 ` Si-Wei Liu
2023-08-15 1:43 ` [PATCH RFC 3/4] vhost-vdpa: should restore 1:1 dma mapping before detaching driver Si-Wei Liu
2023-08-15 2:32 ` Jason Wang
2023-08-15 23:09 ` Si-Wei Liu
2023-08-15 1:43 ` [PATCH RFC 4/4] vhost-vdpa: introduce IOTLB_PERSIST backend feature bit Si-Wei Liu
2023-08-15 2:25 ` Jason Wang
2023-08-15 22:30 ` Si-Wei Liu
2023-08-16 1:48 ` Jason Wang
2023-08-16 23:43 ` Si-Wei Liu
2023-08-22 8:54 ` Jason Wang
2023-08-28 23:46 ` Si-Wei Liu
2023-08-02 17:12 ` [PATCH 2/2] vdpa/mlx5: Delete control vq iotlb in destroy_mr only when necessary Dragos Tatulea
2023-08-10 8:54 ` [PATCH 0/2] vdpa/mlx5: Fixes for ASID handling Michael S. Tsirkin
2023-08-10 8:59 ` Jason Wang
2023-08-10 9:04 ` Dragos Tatulea
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=1692063807-5018-1-git-send-email-si-wei.liu@oracle.com \
--to=si-wei.liu@oracle.com \
--cc=eperezma@redhat.com \
--cc=gal@nvidia.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.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
all inboxes | Powered by JetHome®