qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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



  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).