From: Alex Williamson <alex.williamson@redhat.com>
To: Yulei Zhang <yulei.zhang@intel.com>
Cc: qemu-devel@nongnu.org, kevin.tian@intel.com,
joonas.lahtinen@linux.intel.com, zhenyuw@linux.intel.com,
kwankhede@nvidia.com, zhi.a.wang@intel.com, dgilbert@redhat.com,
quintela@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH V4 3/4] vfio: Add SaveVMHanlders for VFIO device to support live migration
Date: Mon, 16 Apr 2018 14:37:45 -0600 [thread overview]
Message-ID: <20180416143745.3cb868d9@w520.home> (raw)
In-Reply-To: <1523340193-9024-1-git-send-email-yulei.zhang@intel.com>
On Tue, 10 Apr 2018 14:03:13 +0800
Yulei Zhang <yulei.zhang@intel.com> wrote:
> Instead of using vm state description, add SaveVMHandlers for VFIO
> device to support live migration.
>
> Introduce new Ioctl VFIO_DEVICE_GET_DIRTY_BITMAP to fetch the memory
> bitmap that dirtied by vfio device during the iterative precopy stage
> to shorten the system downtime afterward.
>
> For vfio pci device status migrate, during the system downtime, it will
> save the following states
> 1. pci configuration space addr0~addr5
> 2. pci configuration space msi_addr msi_data
> 3. pci device status fetch from device driver
>
> And on the target side the vfio_load will restore the same states
> 1. re-setup the pci bar configuration
> 2. re-setup the pci device msi configuration
> 3. restore the pci device status
Interrupts are configured via ioctl, but I don't see any code here to
configure the device into the correct interrupt state. How do we know
the target device is compatible with the source device? Do we rely on
the vendor driver to implicitly include some kind of device and version
information and fail at the very end of the migration? It seems like
we need to somehow front-load that sort of device compatibility
checking since a vfio-pci device can be anything (ex. what happens if
a user tries to migrate a GVT-g vGPU to an NVIDIA vGPU?). Thanks,
Alex
next prev parent reply other threads:[~2018-04-16 20:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 6:03 [Qemu-devel] [RFC PATCH V4 3/4] vfio: Add SaveVMHanlders for VFIO device to support live migration Yulei Zhang
2018-04-16 14:44 ` Kirti Wankhede
2018-04-17 8:01 ` Zhang, Yulei
2018-04-17 19:41 ` Kirti Wankhede
2018-04-17 19:25 ` Eric Blake
2018-04-16 20:37 ` Alex Williamson [this message]
2018-04-17 8:11 ` Zhang, Yulei
2018-04-17 14:34 ` Alex Williamson
2018-04-18 10:57 ` Zhang, Yulei
2018-04-18 11:18 ` Dr. David Alan Gilbert
2018-04-17 19:19 ` Dr. David Alan Gilbert
2018-05-10 11:51 ` Juan Quintela
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=20180416143745.3cb868d9@w520.home \
--to=alex.williamson@redhat.com \
--cc=dgilbert@redhat.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kevin.tian@intel.com \
--cc=kwankhede@nvidia.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=yulei.zhang@intel.com \
--cc=zhenyuw@linux.intel.com \
--cc=zhi.a.wang@intel.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).