From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Avihai Horon <avihaih@nvidia.com>,
qemu-devel@nongnu.org, Cornelia Huck <cohuck@redhat.com>,
Juan Quintela <quintela@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
Joao Martins <joao.m.martins@oracle.com>,
Yishai Hadas <yishaih@nvidia.com>, Mark Bloch <mbloch@nvidia.com>,
Maor Gottlieb <maorg@nvidia.com>,
Kirti Wankhede <kwankhede@nvidia.com>,
Tarun Gupta <targupta@nvidia.com>
Subject: Re: [PATCH v2 00/11] vfio/migration: Implement VFIO migration protocol v2
Date: Thu, 23 Jun 2022 11:56:47 -0300 [thread overview]
Message-ID: <20220623145647.GA4147@nvidia.com> (raw)
In-Reply-To: <20220617155129.206749cb.alex.williamson@redhat.com>
On Fri, Jun 17, 2022 at 03:51:29PM -0600, Alex Williamson wrote:
> It's ok by me if QEMU vfio is the one that marks all mapped pages dirty
> if the host interface provides no way to do so. Would we toggle that
> based on whether the device has bus-master enabled?
I don't think so, that is a very niche optimization, it would only
happen if a device is plugged in but never used.
If a device truely doesn't have bus master capability at all then it's
VFIO migration driver should implement report dirties and report no
dirties.
> Regarding SPAPR, I'd tend to think that if we're dirtying in QEMU then
> nothing prevents us from implementing the same there, but also I'm not
> going to stand in the way of simply disabling migration for that IOMMU
> backend unless someone speaks up that they think it deserves parity.
If the VFIO device internal tracker is being used it should work with
SPAPR too.
The full algorithm should be to try to find a dirty tracker for each
VFIO migration device and if none is found then always dirty
everything at STOP_COPY.
iommufd will provide the only global dirty tracker, so if SPAPR or
legacy VFIO type1 is used without a device internal tracker then it
should do the all-dirties.
Jason
next prev parent reply other threads:[~2022-06-23 15:07 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-30 17:07 [PATCH v2 00/11] vfio/migration: Implement VFIO migration protocol v2 Avihai Horon
2022-05-30 17:07 ` [PATCH v2 01/11] vfio/migration: Fix NULL pointer dereference bug Avihai Horon
2022-05-30 17:07 ` [PATCH v2 02/11] vfio/migration: Skip pre-copy if dirty page tracking is not supported Avihai Horon
2022-05-30 17:12 ` Avihai Horon
2022-06-07 17:53 ` Avihai Horon
2022-05-30 17:07 ` [PATCH v2 03/11] migration/qemu-file: Add qemu_file_get_to_fd() Avihai Horon
2022-05-30 17:07 ` [PATCH v2 04/11] vfio/common: Change vfio_devices_all_running_and_saving() logic to equivalent one Avihai Horon
2022-05-30 17:07 ` [PATCH v2 05/11] vfio/migration: Move migration v1 logic to vfio_migration_init() Avihai Horon
2022-05-30 17:07 ` [PATCH v2 06/11] vfio/migration: Rename functions/structs related to v1 protocol Avihai Horon
2022-05-30 17:07 ` [PATCH v2 07/11] vfio/migration: Implement VFIO migration protocol v2 Avihai Horon
2022-06-14 11:08 ` Joao Martins
2022-06-14 16:34 ` Avihai Horon
2022-06-14 17:24 ` Joao Martins
2022-06-15 6:40 ` Avihai Horon
2022-07-18 15:12 ` Jason Gunthorpe
2022-07-27 15:45 ` Avihai Horon
2022-05-30 17:07 ` [PATCH v2 08/11] vfio/migration: Remove VFIO migration protocol v1 Avihai Horon
2022-09-19 8:35 ` liulongfang via
2022-09-19 11:50 ` Alex Williamson
2022-09-19 12:58 ` Philippe Mathieu-Daudé via
2022-09-19 9:41 ` Philippe Mathieu-Daudé via
2022-05-30 17:07 ` [PATCH v2 09/11] vfio/migration: Reset device if setting recover state fails Avihai Horon
2022-10-11 1:41 ` liulongfang via
2022-05-30 17:07 ` [PATCH v2 10/11] vfio: Alphabetize migration section of VFIO trace-events file Avihai Horon
2022-05-30 17:07 ` [PATCH v2 11/11] docs/devel: Align vfio-migration docs to VFIO migration v2 Avihai Horon
2022-06-07 17:44 ` [PATCH v2 00/11] vfio/migration: Implement VFIO migration protocol v2 Avihai Horon
2022-06-07 21:32 ` Alex Williamson
2022-06-13 11:21 ` Avihai Horon
2022-06-17 21:51 ` Alex Williamson
2022-06-23 14:56 ` Jason Gunthorpe [this message]
2022-06-27 7:36 ` 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=20220623145647.GA4147@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=avihaih@nvidia.com \
--cc=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=joao.m.martins@oracle.com \
--cc=kwankhede@nvidia.com \
--cc=maorg@nvidia.com \
--cc=mbloch@nvidia.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--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).