From: Kunkun Jiang <jiangkunkun@huawei.com>
To: Eric Auger <eric.auger@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Alex Williamson <alex.williamson@redhat.com>,
<kevin.tian@intel.com>, Yi Sun <yi.y.sun@linux.intel.com>,
"open list:ARM SMMU" <qemu-arm@nongnu.org>,
"open list:All patches CC here" <qemu-devel@nongnu.org>
Cc: Liu Yi L <yi.l.liu@intel.com>,
shameerali.kolothum.thodi@huawei.com,
Kirti Wankhede <kwankhede@nvidia.com>,
Zenghui Yu <yuzenghui@huawei.com>,
wanghaibin.wang@huawei.com, Keqian Zhu <zhukeqian1@huawei.com>
Subject: [RFC PATCH v2 0/4] Add migration support for VFIO PCI devices in SMMUv3 nested stage mode
Date: Wed, 31 Mar 2021 18:12:55 +0800 [thread overview]
Message-ID: <20210331101259.2153-1-jiangkunkun@huawei.com> (raw)
Hi all,
Since the SMMUv3's nested translation stages[1] has been introduced by Eric, we
need to pay attention to the migration of VFIO PCI devices in SMMUv3 nested stage
mode. At present, it is not yet supported in QEMU. There are two problems in the
existing framework.
First, the current way to get dirty pages is not applicable to nested stage mode.
Because of the "Caching Mode", VTD can map the RAM through the host single stage
(giova->hpa). "vfio_listener_log_sync" gets dirty pages by transferring "giova"
to the kernel for the RAM block section of mapped MMIO region. In nested stage
mode, we setup the stage 2 (gpa->hpa) and the stage 1(giova->gpa) separately. So
it is inapplicable to get dirty pages by the current way in nested stage mode.
Second, it also need to pass stage 1 configurations to the destination host after
the migration. In Eric's patch, it passes the stage 1 configuration to the host on
each STE update for the devices set the PASID PciOps. The configuration will be
applied at physical level. But the data of physical level will not be sent to the
destination host. So we have to pass stage 1 configurations to the destination
host after the migration.
Best Regards,
Kunkun Jiang
[1] [RFC,v8,00/28] vSMMUv3/pSMMUv3 2 stage VFIO integration
http://patchwork.ozlabs.org/project/qemu-devel/cover/20210225105233.650545-1-eric.auger@redhat.com/
This Patch set includes patches as below:
Patch 1-2:
- Refactor the vfio_listener_log_sync and added a new function to get dirty pages
in nested stage mode.
Patch 3:
- Added global_log_start/stop interface in vfio_memory_prereg_listener
Patch 4:
- Added the post_load function to vmstate_smmuv3 for passing stage 1 configuration
to the destination host after the migration.
History:
v1 -> v2:
- Add global_log_start/stop interface in vfio_memory_prereg_listener
- Add support for repass stage 1 configs with multiple CDs to the host
Kunkun Jiang (4):
vfio: Introduce helpers to mark dirty pages of a RAM section
vfio: Add vfio_prereg_listener_log_sync in nested stage
vfio: Add vfio_prereg_listener_global_log_start/stop in nested stage
hw/arm/smmuv3: Post-load stage 1 configurations to the host
hw/arm/smmuv3.c | 62 +++++++++++++++++++++++++++++++++++++++
hw/arm/trace-events | 1 +
hw/vfio/common.c | 71 ++++++++++++++++++++++++++++++++++++++++-----
3 files changed, 126 insertions(+), 8 deletions(-)
--
2.23.0
next reply other threads:[~2021-03-31 10:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-31 10:12 Kunkun Jiang [this message]
2021-03-31 10:12 ` [RFC PATCH v2 1/4] vfio: Introduce helpers to mark dirty pages of a RAM section Kunkun Jiang
2021-03-31 10:12 ` [RFC PATCH v2 2/4] vfio: Add vfio_prereg_listener_log_sync in nested stage Kunkun Jiang
2021-03-31 10:12 ` [RFC PATCH v2 3/4] vfio: Add vfio_prereg_listener_global_log_start/stop " Kunkun Jiang
2021-03-31 10:12 ` [RFC PATCH v2 4/4] hw/arm/smmuv3: Post-load stage 1 configurations to the host Kunkun Jiang
2021-05-11 2:23 ` [RFC PATCH v2 0/4] Add migration support for VFIO PCI devices in SMMUv3 nested stage mode Kunkun Jiang
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=20210331101259.2153-1-jiangkunkun@huawei.com \
--to=jiangkunkun@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=eric.auger@redhat.com \
--cc=kevin.tian@intel.com \
--cc=kwankhede@nvidia.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=wanghaibin.wang@huawei.com \
--cc=yi.l.liu@intel.com \
--cc=yi.y.sun@linux.intel.com \
--cc=yuzenghui@huawei.com \
--cc=zhukeqian1@huawei.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).