From: Alex Williamson <alex.williamson@redhat.com>
To: Avihai Horon <avihaih@nvidia.com>
Cc: qemu-devel@nongnu.org, "Cédric Le Goater" <clg@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Eduardo Habkost" <eduardo@habkost.net>,
"David Hildenbrand" <david@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Yishai Hadas" <yishaih@nvidia.com>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Maor Gottlieb" <maorg@nvidia.com>,
"Kirti Wankhede" <kwankhede@nvidia.com>,
"Tarun Gupta" <targupta@nvidia.com>,
"Joao Martins" <joao.m.martins@oracle.com>
Subject: Re: [PATCH v2 10/20] vfio/common: Record DMA mapped IOVA ranges
Date: Wed, 22 Feb 2023 15:10:39 -0700 [thread overview]
Message-ID: <20230222151039.1de95db4.alex.williamson@redhat.com> (raw)
In-Reply-To: <20230222174915.5647-11-avihaih@nvidia.com>
On Wed, 22 Feb 2023 19:49:05 +0200
Avihai Horon <avihaih@nvidia.com> wrote:
> From: Joao Martins <joao.m.martins@oracle.com>
>
> According to the device DMA logging uAPI, IOVA ranges to be logged by
> the device must be provided all at once upon DMA logging start.
>
> As preparation for the following patches which will add device dirty
> page tracking, keep a record of all DMA mapped IOVA ranges so later they
> can be used for DMA logging start.
>
> Note that when vIOMMU is enabled DMA mapped IOVA ranges are not tracked.
> This is due to the dynamic nature of vIOMMU DMA mapping/unmapping.
> Following patches will address the vIOMMU case specifically.
>
> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
> Signed-off-by: Avihai Horon <avihaih@nvidia.com>
> ---
> include/hw/vfio/vfio-common.h | 3 ++
> hw/vfio/common.c | 86 +++++++++++++++++++++++++++++++++--
> 2 files changed, 86 insertions(+), 3 deletions(-)
>
> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
> index ee55d442b4..6f36876ce0 100644
> --- a/include/hw/vfio/vfio-common.h
> +++ b/include/hw/vfio/vfio-common.h
> @@ -23,6 +23,7 @@
>
> #include "exec/memory.h"
> #include "qemu/queue.h"
> +#include "qemu/iova-tree.h"
> #include "qemu/notify.h"
> #include "ui/console.h"
> #include "hw/display/ramfb.h"
> @@ -92,6 +93,8 @@ typedef struct VFIOContainer {
> uint64_t max_dirty_bitmap_size;
> unsigned long pgsizes;
> unsigned int dma_max_mappings;
> + IOVATree *mappings;
> + QemuMutex mappings_mutex;
> QLIST_HEAD(, VFIOGuestIOMMU) giommu_list;
> QLIST_HEAD(, VFIOHostDMAWindow) hostwin_list;
> QLIST_HEAD(, VFIOGroup) group_list;
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 84f08bdbbb..6041da6c7e 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -44,6 +44,7 @@
> #include "migration/blocker.h"
> #include "migration/qemu-file.h"
> #include "sysemu/tpm.h"
> +#include "qemu/iova-tree.h"
>
> VFIOGroupList vfio_group_list =
> QLIST_HEAD_INITIALIZER(vfio_group_list);
> @@ -426,6 +427,11 @@ void vfio_unblock_multiple_devices_migration(void)
> multiple_devices_migration_blocker = NULL;
> }
>
> +static bool vfio_have_giommu(VFIOContainer *container)
> +{
> + return !QLIST_EMPTY(&container->giommu_list);
> +}
> +
> static void vfio_set_migration_error(int err)
> {
> MigrationState *ms = migrate_get_current();
> @@ -499,6 +505,51 @@ static bool vfio_devices_all_running_and_mig_active(VFIOContainer *container)
> return true;
> }
>
> +static int vfio_record_mapping(VFIOContainer *container, hwaddr iova,
> + hwaddr size, bool readonly)
> +{
> + DMAMap map = {
> + .iova = iova,
> + .size = size - 1, /* IOVATree is inclusive, so subtract 1 from size */
> + .perm = readonly ? IOMMU_RO : IOMMU_RW,
> + };
> + int ret;
> +
> + if (vfio_have_giommu(container)) {
> + return 0;
> + }
> +
> + WITH_QEMU_LOCK_GUARD(&container->mappings_mutex) {
> + ret = iova_tree_insert(container->mappings, &map);
> + if (ret) {
> + if (ret == IOVA_ERR_INVALID) {
> + ret = -EINVAL;
> + } else if (ret == IOVA_ERR_OVERLAP) {
> + ret = -EEXIST;
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> +static void vfio_erase_mapping(VFIOContainer *container, hwaddr iova,
> + hwaddr size)
> +{
> + DMAMap map = {
> + .iova = iova,
> + .size = size - 1, /* IOVATree is inclusive, so subtract 1 from size */
> + };
> +
> + if (vfio_have_giommu(container)) {
> + return;
> + }
> +
> + WITH_QEMU_LOCK_GUARD(&container->mappings_mutex) {
> + iova_tree_remove(container->mappings, map);
> + }
> +}
Nit, 'insert' and 'remove' to match the IOVATree semantics?
> static int vfio_dma_unmap_bitmap(VFIOContainer *container,
> hwaddr iova, ram_addr_t size,
> IOMMUTLBEntry *iotlb)
> @@ -599,6 +650,8 @@ static int vfio_dma_unmap(VFIOContainer *container,
> DIRTY_CLIENTS_NOCODE);
> }
>
> + vfio_erase_mapping(container, iova, size);
> +
> return 0;
> }
>
> @@ -612,6 +665,16 @@ static int vfio_dma_map(VFIOContainer *container, hwaddr iova,
> .iova = iova,
> .size = size,
> };
> + int ret;
> +
> + ret = vfio_record_mapping(container, iova, size, readonly);
> + if (ret) {
> + error_report("vfio: Failed to record mapping, iova: 0x%" HWADDR_PRIx
> + ", size: 0x" RAM_ADDR_FMT ", ret: %d (%s)",
> + iova, size, ret, strerror(-ret));
> +
> + return ret;
> + }
Is there no way to replay the mappings when a migration is started?
This seems like a horrible latency and bloat trade-off for the
possibility that the VM might migrate and the device might support
these features. Our performance with vIOMMU is already terrible, I
can't help but believe this makes it worse. Thanks,
Alex
next prev parent reply other threads:[~2023-02-22 22:11 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-22 17:48 [PATCH v2 00/20] vfio: Add migration pre-copy support and device dirty tracking Avihai Horon
2023-02-22 17:48 ` [PATCH v2 01/20] migration: Pass threshold_size to .state_pending_{estimate, exact}() Avihai Horon via
2023-02-22 17:48 ` [PATCH v2 02/20] vfio/migration: Refactor vfio_save_block() to return saved data size Avihai Horon
2023-02-27 14:10 ` Cédric Le Goater
2023-02-22 17:48 ` [PATCH v2 03/20] vfio/migration: Add VFIO migration pre-copy support Avihai Horon
2023-02-22 20:58 ` Alex Williamson
2023-02-23 15:25 ` Avihai Horon
2023-02-23 21:16 ` Alex Williamson
2023-02-26 16:43 ` Avihai Horon
2023-02-27 16:14 ` Alex Williamson
2023-02-27 17:26 ` Jason Gunthorpe
2023-02-27 17:43 ` Alex Williamson
2023-03-01 18:49 ` Avihai Horon
2023-03-01 19:55 ` Alex Williamson
2023-03-01 21:12 ` Jason Gunthorpe
2023-03-01 22:39 ` Alex Williamson
2023-03-06 19:01 ` Jason Gunthorpe
2023-02-22 17:48 ` [PATCH v2 04/20] vfio/common: Fix error reporting in vfio_get_dirty_bitmap() Avihai Horon
2023-02-22 17:49 ` [PATCH v2 05/20] vfio/common: Fix wrong %m usages Avihai Horon
2023-02-22 17:49 ` [PATCH v2 06/20] vfio/common: Abort migration if dirty log start/stop/sync fails Avihai Horon
2023-02-22 17:49 ` [PATCH v2 07/20] vfio/common: Add VFIOBitmap and (de)alloc functions Avihai Horon
2023-02-22 21:40 ` Alex Williamson
2023-02-23 15:27 ` Avihai Horon
2023-02-27 14:09 ` Cédric Le Goater
2023-03-01 18:56 ` Avihai Horon
2023-03-02 13:24 ` Joao Martins
2023-03-02 14:52 ` Cédric Le Goater
2023-03-02 16:30 ` Joao Martins
2023-03-04 0:23 ` Joao Martins
2023-02-22 17:49 ` [PATCH v2 08/20] util: Add iova_tree_nnodes() Avihai Horon
2023-02-22 17:49 ` [PATCH v2 09/20] util: Extend iova_tree_foreach() to take data argument Avihai Horon
2023-02-22 17:49 ` [PATCH v2 10/20] vfio/common: Record DMA mapped IOVA ranges Avihai Horon
2023-02-22 22:10 ` Alex Williamson [this message]
2023-02-23 10:37 ` Joao Martins
2023-02-23 21:05 ` Alex Williamson
2023-02-23 21:19 ` Joao Martins
2023-02-23 21:50 ` Alex Williamson
2023-02-23 21:54 ` Joao Martins
2023-02-28 12:11 ` Joao Martins
2023-02-28 20:36 ` Alex Williamson
2023-03-02 0:07 ` Joao Martins
2023-03-02 0:13 ` Joao Martins
2023-03-02 18:42 ` Alex Williamson
2023-03-03 0:19 ` Joao Martins
2023-03-03 16:58 ` Joao Martins
2023-03-03 17:05 ` Alex Williamson
2023-03-03 19:14 ` Joao Martins
2023-03-03 19:40 ` Alex Williamson
2023-03-03 20:16 ` Joao Martins
2023-03-03 23:47 ` Alex Williamson
2023-03-03 23:57 ` Joao Martins
2023-03-04 0:21 ` Joao Martins
2023-02-22 17:49 ` [PATCH v2 11/20] vfio/common: Add device dirty page tracking start/stop Avihai Horon
2023-02-22 22:40 ` Alex Williamson
2023-02-23 2:02 ` Jason Gunthorpe
2023-02-23 19:27 ` Alex Williamson
2023-02-23 19:30 ` Jason Gunthorpe
2023-02-23 20:16 ` Alex Williamson
2023-02-23 20:54 ` Jason Gunthorpe
2023-02-26 16:54 ` Avihai Horon
2023-02-23 15:36 ` Avihai Horon
2023-02-22 17:49 ` [PATCH v2 12/20] vfio/common: Extract code from vfio_get_dirty_bitmap() to new function Avihai Horon
2023-02-22 17:49 ` [PATCH v2 13/20] vfio/common: Add device dirty page bitmap sync Avihai Horon
2023-02-22 17:49 ` [PATCH v2 14/20] vfio/common: Extract vIOMMU code from vfio_sync_dirty_bitmap() Avihai Horon
2023-02-22 17:49 ` [PATCH v2 15/20] memory/iommu: Add IOMMU_ATTR_MAX_IOVA attribute Avihai Horon
2023-02-22 17:49 ` [PATCH v2 16/20] intel-iommu: Implement get_attr() method Avihai Horon
2023-02-22 17:49 ` [PATCH v2 17/20] vfio/common: Support device dirty page tracking with vIOMMU Avihai Horon
2023-02-22 23:34 ` Alex Williamson
2023-02-23 2:08 ` Jason Gunthorpe
2023-02-23 20:06 ` Alex Williamson
2023-02-23 20:55 ` Jason Gunthorpe
2023-02-23 21:30 ` Joao Martins
2023-02-23 22:33 ` Alex Williamson
2023-02-23 23:26 ` Jason Gunthorpe
2023-02-24 11:25 ` Joao Martins
2023-02-24 12:53 ` Joao Martins
2023-02-24 15:47 ` Jason Gunthorpe
2023-02-24 15:56 ` Alex Williamson
2023-02-24 19:16 ` Joao Martins
2023-02-22 17:49 ` [PATCH v2 18/20] vfio/common: Optimize " Avihai Horon
2023-02-22 17:49 ` [PATCH v2 19/20] vfio/migration: Query device dirty page tracking support Avihai Horon
2023-02-22 17:49 ` [PATCH v2 20/20] docs/devel: Document VFIO device dirty page tracking Avihai Horon
2023-02-27 14:29 ` Cédric Le Goater
2023-02-22 18:00 ` [PATCH v2 00/20] vfio: Add migration pre-copy support and device dirty tracking Avihai Horon
2023-02-22 20:55 ` Alex Williamson
2023-02-23 10:05 ` Cédric Le Goater
2023-02-23 15:07 ` Avihai Horon
2023-02-27 10:24 ` Cédric Le Goater
2023-02-23 14:56 ` Avihai Horon
2023-02-24 19:26 ` Joao Martins
2023-02-26 17:00 ` Avihai Horon
2023-02-27 13:50 ` Cédric Le Goater
2023-03-01 19:04 ` Avihai Horon
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=20230222151039.1de95db4.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=avihaih@nvidia.com \
--cc=clg@redhat.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eduardo@habkost.net \
--cc=jasowang@redhat.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=kwankhede@nvidia.com \
--cc=maorg@nvidia.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=targupta@nvidia.com \
--cc=yishaih@nvidia.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).