linux-kernel - Re: [PATCH v4 0/2] introduction of migration_version attribute for VFIO live migration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190603132932.1b5dc7fe@x1.home>
Date:   Mon, 3 Jun 2019 13:29:32 -0600
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Yan Zhao <yan.y.zhao@...el.com>
Cc:     intel-gvt-dev@...ts.freedesktop.org, aik@...abs.ru,
        Zhengxiao.zx@...baba-inc.com, shuangtai.tst@...baba-inc.com,
        qemu-devel@...gnu.org, eauger@...hat.com, yi.l.liu@...el.com,
        ziye.yang@...el.com, mlevitsk@...hat.com, pasic@...ux.ibm.com,
        felipe@...anix.com, changpeng.liu@...el.com, Ken.Xue@....com,
        jonathan.davies@...anix.com, shaopeng.he@...el.com,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        libvir-list@...hat.com, eskultet@...hat.com, dgilbert@...hat.com,
        cohuck@...hat.com, kevin.tian@...el.com, zhenyuw@...ux.intel.com,
        zhi.a.wang@...el.com, cjia@...dia.com, kwankhede@...dia.com,
        berrange@...hat.com, dinechin@...hat.com
Subject: Re: [PATCH v4 0/2] introduction of migration_version attribute for
 VFIO live migration

On Thu, 30 May 2019 20:44:38 -0400
Yan Zhao <yan.y.zhao@...el.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