From: Alex Williamson <alex.williamson@redhat.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: qemu-devel@nongnu.org, Cedric Le Goater <clg@redhat.com>,
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>
Subject: Re: [PATCH v3 00/13] vfio/migration: Device dirty page tracking
Date: Sun, 5 Mar 2023 13:57:34 -0700 [thread overview]
Message-ID: <20230305135734.71d54dd1.alex.williamson@redhat.com> (raw)
In-Reply-To: <20230304014343.33646-1-joao.m.martins@oracle.com>
On Sat, 4 Mar 2023 01:43:30 +0000
Joao Martins <joao.m.martins@oracle.com> wrote:
> Hey,
>
> Presented herewith a series based on the basic VFIO migration protocol v2
> implementation [1].
>
> It is split from its parent series[5] to solely focus on device dirty
> page tracking. Device dirty page tracking allows the VFIO device to
> record its DMAs and report them back when needed. This is part of VFIO
> migration and is used during pre-copy phase of migration to track the
> RAM pages that the device has written to and mark those pages dirty, so
> they can later be re-sent to target.
>
> Device dirty page tracking uses the DMA logging uAPI to discover device
> capabilities, to start and stop tracking, and to get dirty page bitmap
> report. Extra details and uAPI definition can be found here [3].
>
> Device dirty page tracking operates in VFIOContainer scope. I.e., When
> dirty tracking is started, stopped or dirty page report is queried, all
> devices within a VFIOContainer are iterated and for each of them device
> dirty page tracking is started, stopped or dirty page report is queried,
> respectively.
>
> Device dirty page tracking is used only if all devices within a
> VFIOContainer support it. Otherwise, VFIO IOMMU dirty page tracking is
> used, and if that is not supported as well, memory is perpetually marked
> dirty by QEMU. Note that since VFIO IOMMU dirty page tracking has no HW
> support, the last two usually have the same effect of perpetually
> marking all pages dirty.
>
> Normally, when asked to start dirty tracking, all the currently DMA
> mapped ranges are tracked by device dirty page tracking. If using a
> vIOMMU we block live migration. It's temporary and a separate series is
> going to add support for it. Thus this series focus on getting the
> ground work first.
>
> The series is organized as follows:
>
> - Patches 1-7: Fix bugs and do some preparatory work required prior to
> adding device dirty page tracking.
> - Patches 8-10: Implement device dirty page tracking.
> - Patch 11: Blocks live migration with vIOMMU.
> - Patches 12-13 enable device dirty page tracking and document it.
>
> Comments, improvements as usual appreciated.
Still some CI failures:
https://gitlab.com/alex.williamson/qemu/-/pipelines/796657474
The docker failures are normal, afaict the rest are not. Thanks,
Alex
next prev parent reply other threads:[~2023-03-05 20:58 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-04 1:43 [PATCH v3 00/13] vfio/migration: Device dirty page tracking Joao Martins
2023-03-04 1:43 ` [PATCH v3 01/13] vfio/common: Fix error reporting in vfio_get_dirty_bitmap() Joao Martins
2023-03-04 1:43 ` [PATCH v3 02/13] vfio/common: Fix wrong %m usages Joao Martins
2023-03-04 1:43 ` [PATCH v3 03/13] vfio/common: Abort migration if dirty log start/stop/sync fails Joao Martins
2023-03-04 1:43 ` [PATCH v3 04/13] vfio/common: Add VFIOBitmap and alloc function Joao Martins
2023-03-06 13:20 ` Cédric Le Goater
2023-03-06 14:37 ` Joao Martins
2023-03-04 1:43 ` [PATCH v3 05/13] vfio/common: Add helper to validate iova/end against hostwin Joao Martins
2023-03-06 13:24 ` Cédric Le Goater
2023-03-04 1:43 ` [PATCH v3 06/13] vfio/common: Consolidate skip/invalid section into helper Joao Martins
2023-03-06 13:33 ` Cédric Le Goater
2023-03-04 1:43 ` [PATCH v3 07/13] vfio/common: Record DMA mapped IOVA ranges Joao Martins
2023-03-06 13:41 ` Cédric Le Goater
2023-03-06 14:37 ` Joao Martins
2023-03-06 15:11 ` Alex Williamson
2023-03-06 18:05 ` Cédric Le Goater
2023-03-06 19:45 ` Joao Martins
2023-03-06 18:15 ` Alex Williamson
2023-03-06 19:32 ` Joao Martins
2023-03-04 1:43 ` [PATCH v3 08/13] vfio/common: Add device dirty page tracking start/stop Joao Martins
2023-03-06 18:25 ` Cédric Le Goater
2023-03-06 18:42 ` Alex Williamson
2023-03-06 19:39 ` Joao Martins
2023-03-06 20:00 ` Alex Williamson
2023-03-06 23:12 ` Joao Martins
2023-03-04 1:43 ` [PATCH v3 09/13] vfio/common: Extract code from vfio_get_dirty_bitmap() to new function Joao Martins
2023-03-06 16:24 ` Cédric Le Goater
2023-03-04 1:43 ` [PATCH v3 10/13] vfio/common: Add device dirty page bitmap sync Joao Martins
2023-03-06 19:22 ` Alex Williamson
2023-03-06 19:42 ` Joao Martins
2023-03-04 1:43 ` [PATCH v3 11/13] vfio/migration: Block migration with vIOMMU Joao Martins
2023-03-06 17:00 ` Cédric Le Goater
2023-03-06 17:04 ` Joao Martins
2023-03-06 19:42 ` Alex Williamson
2023-03-06 23:10 ` Joao Martins
2023-03-04 1:43 ` [PATCH v3 12/13] vfio/migration: Query device dirty page tracking support Joao Martins
2023-03-06 17:20 ` Cédric Le Goater
2023-03-04 1:43 ` [PATCH v3 13/13] docs/devel: Document VFIO device dirty page tracking Joao Martins
2023-03-06 17:15 ` Cédric Le Goater
2023-03-06 17:18 ` Joao Martins
2023-03-06 17:21 ` Joao Martins
2023-03-06 17:21 ` Cédric Le Goater
2023-03-05 20:57 ` Alex Williamson [this message]
2023-03-05 23:33 ` [PATCH v3 00/13] vfio/migration: Device " Joao Martins
2023-03-06 2:19 ` Alex Williamson
2023-03-06 9:45 ` Joao Martins
2023-03-06 11:05 ` Cédric Le Goater
2023-03-06 21:19 ` Alex Williamson
2023-03-06 17:23 ` Cédric Le Goater
2023-03-06 19:41 ` Joao Martins
2023-03-07 8:33 ` 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=20230305135734.71d54dd1.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=clg@redhat.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=kwankhede@nvidia.com \
--cc=maorg@nvidia.com \
--cc=qemu-devel@nongnu.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).