Re: [Qemu-devel] [PATCH 0/5] QEMU VFIO live migration

[Gonglei (Arei)]

> -----Original Message-----
> From: Cornelia Huck [mailto:address@hidden
> Sent: Wednesday, February 20, 2019 7:43 PM
> To: Gonglei (Arei) <address@hidden>
> Cc: Dr. David Alan Gilbert <address@hidden>; Zhao Yan
> <address@hidden>; address@hidden; address@hidden;
> address@hidden; address@hidden; address@hidden;
> address@hidden; address@hidden; address@hidden;
> address@hidden; address@hidden; address@hidden;
> address@hidden; address@hidden; address@hidden;
> address@hidden; address@hidden; address@hidden;
> address@hidden; address@hidden;
> address@hidden; address@hidden
> Subject: Re: [PATCH 0/5] QEMU VFIO live migration
> 
> On Wed, 20 Feb 2019 11:28:46 +0000
> "Gonglei (Arei)" <address@hidden> wrote:
> 
> > > -----Original Message-----
> > > From: Dr. David Alan Gilbert [mailto:address@hidden
> > > Sent: Wednesday, February 20, 2019 7:02 PM
> > > To: Zhao Yan <address@hidden>
> > > Cc: address@hidden; address@hidden; address@hidden;
> > > address@hidden; address@hidden;
> > > address@hidden; address@hidden; address@hidden;
> > > address@hidden; address@hidden; address@hidden;
> > > address@hidden; address@hidden; Gonglei (Arei)
> > > <address@hidden>; address@hidden; address@hidden;
> > > address@hidden; address@hidden;
> > > address@hidden; address@hidden;
> > > address@hidden; address@hidden;
> address@hidden
> > > Subject: Re: [PATCH 0/5] QEMU VFIO live migration
> > >
> > > * Zhao Yan (address@hidden) wrote:
> > > > On Tue, Feb 19, 2019 at 11:32:13AM +0000, Dr. David Alan Gilbert wrote:
> > > > > * Yan Zhao (address@hidden) wrote:
> > > > > > This patchset enables VFIO devices to have live migration 
> > > > > > capability.
> > > > > > Currently it does not support post-copy phase.
> > > > > >
> > > > > > It follows Alex's comments on last version of VFIO live migration
> patches,
> > > > > > including device states, VFIO device state region layout, dirty 
> > > > > > bitmap's
> > > > > > query.
> 
> > > > >   b) How do we detect if we're migrating from/to the wrong device or
> > > > > version of device?  Or say to a device with older firmware or perhaps
> > > > > a device that has less device memory ?
> > > > Actually it's still an open for VFIO migration. Need to think about
> > > > whether it's better to check that in libvirt or qemu (like a device 
> > > > magic
> > > > along with verion ?).
> >
> > We must keep the hardware generation is the same with one POD of public
> cloud
> > providers. But we still think about the live migration between from the the
> lower
> > generation of hardware migrated to the higher generation.
> 
> Agreed, lower->higher is the one direction that might make sense to
> support.
> 
> But regardless of that, I think we need to make sure that incompatible
> devices/versions fail directly instead of failing in a subtle, hard to
> debug way. Might be useful to do some initial sanity checks in libvirt
> as well.
> 
> How easy is it to obtain that information in a form that can be
> consumed by higher layers? Can we find out the device type at least?
> What about some kind of revision?

We can provide an interface to query if the VM support live migration or not
in prepare phase of Libvirt.

Can we get the revision_id from the vendor driver ? before invoking

register_savevm_live(NULL, TYPE_VFIO_PCI, -1,
            revision_id,
            &savevm_vfio_handlers,
            vdev);

then limit the live migration form higher gens to lower gens?

Regards,
-Gonglei