[PATCH 0/5] QEMU VFIO live migration
Cornelia Huck
cohuck at redhat.com
Mon Apr 1 08:14:30 UTC 2019
On Wed, 27 Mar 2019 16:10:20 -0600
Alex Williamson <alex.williamson at redhat.com> wrote:
> On Wed, 27 Mar 2019 20:18:54 +0000
> "Dr. David Alan Gilbert" <dgilbert at redhat.com> wrote:
>
> > * Zhao Yan (yan.y.zhao at intel.com) wrote:
> > > On Wed, Feb 20, 2019 at 07:42:42PM +0800, Cornelia Huck wrote:
> > > > > > > > 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?
> > > hi Alex and Cornelia
> > > for device compatibility, do you think it's a good idea to use "version"
> > > and "device version" fields?
> > >
> > > version field: identify live migration interface's version. it can have a
> > > sort of backward compatibility, like target machine's version >= source
> > > machine's version. something like that.
>
> Don't we essentially already have this via the device specific region?
> The struct vfio_info_cap_header includes id and version fields, so we
> can declare a migration id and increment the version for any
> incompatible changes to the protocol.
>
> > >
> > > device_version field consists two parts:
> > > 1. vendor id : it takes 32 bits. e.g. 0x8086.
>
> Who allocates IDs? If we're going to use PCI vendor IDs, then I'd
> suggest we use a bit to flag it as such so we can reserve that portion
> of the 32bit address space. See for example:
>
> #define VFIO_REGION_TYPE_PCI_VENDOR_TYPE (1 << 31)
> #define VFIO_REGION_TYPE_PCI_VENDOR_MASK (0xffff)
>
> For vendor specific regions.
Just browsing through the thread... if I don't misunderstand, we could
use a vfio-ccw region type id here for ccw, couldn't we? Just to make
sure that this is not pci-specific.
More information about the intel-gvt-dev
mailing list