From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Yulei Zhang <yulei.zhang@intel.com>
Cc: qemu-devel@nongnu.org, kevin.tian@intel.com,
alex.williamson@redhat.com, kwankhede@nvidia.com,
zhenyuw@linux.intel.com
Subject: Re: [Qemu-devel] [PATCH V3 1/4] vfio: introduce a new VFIO subregion for mdev device migration support
Date: Fri, 9 Mar 2018 11:43:11 +0000 [thread overview]
Message-ID: <20180309114311.GA3214@work-vm> (raw)
In-Reply-To: <1520229653-10658-2-git-send-email-yulei.zhang@intel.com>
* Yulei Zhang (yulei.zhang@intel.com) wrote:
> New VFIO sub region VFIO_REGION_SUBTYPE_DEVICE_STATE is added
> to fetch and restore the status of mdev device vGPU during the
> live migration.
>
> Signed-off-by: Yulei Zhang <yulei.zhang@intel.com>
> ---
> hw/vfio/pci.c | 14 +++++++++++++-
> hw/vfio/pci.h | 1 +
> linux-headers/linux/vfio.h | 9 ++++++---
> 3 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 31e1edf..2fe20e4 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -37,6 +37,7 @@
>
> static void vfio_disable_interrupts(VFIOPCIDevice *vdev);
> static void vfio_mmap_set_enabled(VFIOPCIDevice *vdev, bool enabled);
> +static VMStateDescription vfio_pci_vmstate;
>
> /*
> * Disabling BAR mmaping can be slow, but toggling it around INTx can
> @@ -2813,6 +2814,17 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
> vfio_vga_quirk_setup(vdev);
> }
>
> + struct vfio_region_info *device_state;
> + /* device state region setup */
> + if (!vfio_get_dev_region_info(&vdev->vbasedev,
> + VFIO_REGION_TYPE_PCI_VENDOR_TYPE | PCI_VENDOR_ID_INTEL,
> + VFIO_REGION_SUBTYPE_DEVICE_STATE, &device_state)) {
> + memcpy(&vdev->device_state, device_state,
> + sizeof(struct vfio_region_info));
> + g_free(device_state);
> + vfio_pci_vmstate.unmigratable = 0;
> + }
I don't think we've got any other code that changes the 'unmigratable'
flag on a vmstate. If you've got a device that you don't know whether
it's migratable until runtime, then you should add a 'migration blocker'
if the device isn't migratable.
See for example the calls to migrate_add_blocker in hw/virtio/vhost.c
Dave
> for (i = 0; i < PCI_ROM_SLOT; i++) {
> vfio_bar_quirk_setup(vdev, i);
> }
> @@ -2994,7 +3006,7 @@ static Property vfio_pci_dev_properties[] = {
> DEFINE_PROP_END_OF_LIST(),
> };
>
> -static const VMStateDescription vfio_pci_vmstate = {
> +static VMStateDescription vfio_pci_vmstate = {
> .name = "vfio-pci",
> .unmigratable = 1,
> };
> diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
> index a8366bb..6a1d26e 100644
> --- a/hw/vfio/pci.h
> +++ b/hw/vfio/pci.h
> @@ -116,6 +116,7 @@ typedef struct VFIOPCIDevice {
> VFIOBAR bars[PCI_NUM_REGIONS - 1]; /* No ROM */
> VFIOVGA *vga; /* 0xa0000, 0x3b0, 0x3c0 */
> void *igd_opregion;
> + struct vfio_region_info device_state;
> PCIHostDeviceAddress host;
> EventNotifier err_notifier;
> EventNotifier req_notifier;
> diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
> index 4e7ab4c..c3b8e4a 100644
> --- a/linux-headers/linux/vfio.h
> +++ b/linux-headers/linux/vfio.h
> @@ -296,9 +296,12 @@ struct vfio_region_info_cap_type {
> #define VFIO_REGION_TYPE_PCI_VENDOR_MASK (0xffff)
>
> /* 8086 Vendor sub-types */
> -#define VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION (1)
> -#define VFIO_REGION_SUBTYPE_INTEL_IGD_HOST_CFG (2)
> -#define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG (3)
> +#define VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION (1)
> +#define VFIO_REGION_SUBTYPE_INTEL_IGD_HOST_CFG (2)
> +#define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG (3)
> +
> +/* Mdev sub-type for device state save and restore */
> +#define VFIO_REGION_SUBTYPE_DEVICE_STATE (4)
>
> /**
> * VFIO_DEVICE_GET_IRQ_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 9,
> --
> 2.7.4
>
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2018-03-09 11:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-05 6:00 [Qemu-devel] [PATCH V3 0/4] vfio: Introduce Live migration capability to vfio_mdev device Yulei Zhang
2018-03-05 6:00 ` no-reply
2018-03-05 6:00 ` [Qemu-devel] [PATCH V3 1/4] vfio: introduce a new VFIO subregion for mdev device migration support Yulei Zhang
2018-03-09 11:43 ` Dr. David Alan Gilbert [this message]
2018-03-13 8:27 ` Zhang, Yulei
2018-03-05 6:00 ` [Qemu-devel] [PATCH V3 2/4] vfio: Add vm status change callback to stop/restart the mdev device Yulei Zhang
2018-03-05 6:00 ` [Qemu-devel] [PATCH V3 3/4] vfio: Add struct vfio_vmstate_info to introduce put/get callback funtion for vfio device status save/restore Yulei Zhang
2018-03-09 11:59 ` Dr. David Alan Gilbert
2018-03-14 8:52 ` Zhang, Yulei
2018-03-05 6:00 ` [Qemu-devel] [PATCH V3 4/4] vifo: introduce new VFIO ioctl VFIO_IOMMU_GET_DIRTY_BITMAP Yulei Zhang
2018-03-05 13:02 ` [Qemu-devel] [PATCH V3 0/4] vfio: Introduce Live migration capability to vfio_mdev device Kirti Wankhede
2018-03-06 13:34 ` Zhang, Yulei
2018-03-07 2:11 ` Tian, Kevin
2018-03-12 22:21 ` Alex Williamson
2018-03-13 8:16 ` Zhang, Yulei
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=20180309114311.GA3214@work-vm \
--to=dgilbert@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=kevin.tian@intel.com \
--cc=kwankhede@nvidia.com \
--cc=qemu-devel@nongnu.org \
--cc=yulei.zhang@intel.com \
--cc=zhenyuw@linux.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).