Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 3 Jun 2019 13:29:32 -0600
From:   Alex Williamson <alex.williamson@redhat.com>
To:     Yan Zhao <yan.y.zhao@intel.com>
Cc:     intel-gvt-dev@lists.freedesktop.org, aik@ozlabs.ru,
        Zhengxiao.zx@alibaba-inc.com, shuangtai.tst@alibaba-inc.com,
        qemu-devel@nongnu.org, eauger@redhat.com, yi.l.liu@intel.com,
        ziye.yang@intel.com, mlevitsk@redhat.com, pasic@linux.ibm.com,
        felipe@nutanix.com, changpeng.liu@intel.com, Ken.Xue@amd.com,
        jonathan.davies@nutanix.com, shaopeng.he@intel.com,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        libvir-list@redhat.com, eskultet@redhat.com, dgilbert@redhat.com,
        cohuck@redhat.com, kevin.tian@intel.com, zhenyuw@linux.intel.com,
        zhi.a.wang@intel.com, cjia@nvidia.com, kwankhede@nvidia.com,
        berrange@redhat.com, dinechin@redhat.com
Subject: Re: [PATCH v4 0/2] introduction of migration_version attribute for
 VFIO live migration
Message-ID: <20190603132932.1b5dc7fe@x1.home>
In-Reply-To: <20190531004438.24528-1-yan.y.zhao@intel.com>
References: <20190531004438.24528-1-yan.y.zhao@intel.com>
Organization: Red Hat
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 30 May 2019 20:44:38 -0400
Yan Zhao <yan.y.zhao@intel.com> wrote:

> This patchset introduces a migration_version attribute under sysfs of VFIO
> Mediated devices.
> 
> This migration_version attribute is used to check migration compatibility
> between two mdev devices of the same mdev type.
> 
> Patch 1 defines migration_version attribute in
> Documentation/vfio-mediated-device.txt
> 
> Patch 2 uses GVT as an example to show how to expose migration_version
> attribute and check migration compatibility in vendor driver.

Thanks for iterating through this, it looks like we've settled on
something reasonable, but now what?  This is one piece of the puzzle to
supporting mdev migration, but I don't think it makes sense to commit
this upstream on its own without also defining the remainder of how we
actually do migration, preferably with more than one working
implementation and at least prototyped, if not final, QEMU support.  I
hope that was the intent, and maybe it's now time to look at the next
piece of the puzzle.  Thanks,

Alex