RE: device compatibility interface for live migration with assigned devices

To: Zhao, Yan Y <yan.y.zhao(a)intel.com&gt; Cc: Sean Mooney <smooney(a)redhat.com>; Cornelia Huck <cohuck(a)redhat.com>; Daniel P.Berrangé <berrange(a)redhat.com>; kvm(a)vger.kernel.org; libvir-list(a)redhat.com; Jason Wang <jasowang(a)redhat.com>; qemu-devel(a)nongnu.org; kwankhede(a)nvidia.com; eauger(a)redhat.com; Wang, Xin-ran <xin- ran.wang(a)intel.com>; corbet(a)lwn.net; openstack- discuss(a)lists.openstack.org; Feng, Shaohe <shaohe.feng(a)intel.com>; Tian, Kevin <kevin.tian(a)intel.com>; Parav Pandit <parav(a)mellanox.com>; Ding, Jian-feng <jian-feng.ding(a)intel.com>; dgilbert(a)redhat.com; zhenyuw(a)linux.intel.com; Xu, Hejie <hejie.xu(a)intel.com>; bao.yumeng(a)zte.com.cn; intel-gvt-dev(a)lists.freedesktop.org; eskultet(a)redhat.com; Jiri Pirko <jiri(a)mellanox.com>; dinechin(a)redhat.com; devel(a)ovirt.org Subject: Re: device compatibility interface for live migration with assigned devices On Fri, 11 Sep 2020 08:56:00 +0800 Yan Zhao <yan.y.zhao(a)intel.com&gt; wrote: > On Thu, Sep 10, 2020 at 12:02:44PM -0600, Alex Williamson wrote: > > On Thu, 10 Sep 2020 13:50:11 +0100 > > Sean Mooney <smooney(a)redhat.com&gt; wrote: > > > > > On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote: > > > > On Wed, 9 Sep 2020 10:13:09 +0800 > > > > Yan Zhao <yan.y.zhao(a)intel.com&gt; wrote: > > > > > > > > > > > still, I'd like to put it more explicitly to make ensure it's not missed: > > > > > > > the reason we want to specify compatible_type as a trait and check > > > > > > > whether target compatible_type is the superset of source > > > > > > > compatible_type is for the consideration of backward compatibility. > > > > > > > e.g. > > > > > > > an old generation device may have a mdev type xxx-v4-yyy, while a newer > > > > > > > generation device may be of mdev type xxx-v5-yyy. > > > > > > > with the compatible_type traits, the old generation device is still > > > > > > > able to be regarded as compatible to newer generation device even their > > > > > > > mdev types are not equal. > > > > > > > > > > > > If you want to support migration from v4 to v5, can't the (presumably > > > > > > newer) driver that supports v5 simply register the v4 type as well, so > > > > > > that the mdev can be created as v4? (Just like QEMU versioned machine > > > > > > types work.) > > > > > > > > > > yes, it should work in some conditions. > > > > > but it may not be that good in some cases when v5 and v4 in the name string > > > > > of mdev type identify hardware generation (e.g. v4 for gen8, and v5 for > > > > > gen9) > > > > > > > > > > e.g. > > > > > (1). when src mdev type is v4 and target mdev type is v5 as > > > > > software does not support it initially, and v4 and v5 identify hardware > > > > > differences. > > > > > > > > My first hunch here is: Don't introduce types that may be compatible > > > > later. Either make them compatible, or make them distinct by design, > > > > and possibly add a different, compatible type later. > > > > > > > > > then after software upgrade, v5 is now compatible to v4, should the > > > > > software now downgrade mdev type from v5 to v4? > > > > > not sure if moving hardware generation info into a separate attribute > > > > > from mdev type name is better. e.g. remove v4, v5 in mdev type, while use > > > > > compatible_pci_ids to identify compatibility. > > > > > > > > If the generations are compatible, don't mention it in the mdev type. > > > > If they aren't, use distinct types, so that management software doesn't > > > > have to guess. At least that would be my naive approach here. > > > yep that is what i would prefer to see too. > > > > > > > > > > > > > > (2) name string of mdev type is composed by "driver_name + type_name". > > > > > in some devices, e.g. qat, different generations of devices are binding to > > > > > drivers of different names, e.g. "qat-v4", "qat-v5". > > > > > then though type_name is equal, mdev type is not equal. e.g. > > > > > "qat-v4-type1", "qat-v5-type1". > > > > > > > > I guess that shows a shortcoming of that "driver_name + type_name" > > > > approach? Or maybe I'm just confused. > > > yes i really dont like haveing the version in the mdev-type name > > > i would stongly perfger just qat-type-1 wehere qat is just there as a way of namespacing. > > > although symmetric-cryto, asymmetric-cryto and compression woudl be a better name then type-1, type-2, type-3 if > > > that is what they would end up mapping too. e.g. qat-compression or qat-aes is a much better name then type-1 > > > higher layers of software are unlikely to parse the mdev names but as a human looking at them its much eaiser to > > > understand if the names are meaningful. the qat prefix i think is important however to make sure that your mdev-types > > > dont colide with other vendeors mdev types. so i woudl encurage all vendors to prefix there mdev types with etiher the > > > device name or the vendor. > > > > +1 to all this, the mdev type is meant to indicate a software > > compatible interface, if different hardware versions can be software > > compatible, then don't make the job of finding a compatible device > > harder. The full type is a combination of the vendor driver name plus > > the vendor provided type name specifically in order to provide a type > > namespace per vendor driver. That's done at the mdev core level. > > Thanks, > > hi Alex, > got it. so do you suggest that vendors use consistent driver name over > generations of devices? > for qat, they create different modules for each generation. This > practice is not good if they want to support migration between devices > of different generations, right? > > and can I understand that we don't want support of migration between > different mdev types even in future ? You need to balance your requirements here. If you're creating different drivers per generation, that suggests different device APIs, which is a legitimate use case for different mdev types. However if you're expecting migration compatibility, that must be seamless to the guest, therefore the device API must be identical. That suggests that migration between different types doesn't make much sense. If a new generation device wants to expose a new mdev type with new features or device API, yet also support migration with an older mdev type, why wouldn't it simply expose both the old and the new type?

It seems much more supportable to simply instantiate an instance of the older type than to create an instance of the new type, which by the contents of the migration stream is configured to behave as the older type. The latter sounds very difficult to test. A challenge when we think about migration between different types, particularly across different vendor drivers, is that the migration stream is opaque, it's device and vendor specific. Therefore it's not only difficult for userspace to understand the compatibility matrix, but also to actually support it in software, maintaining version and bug compatibility across different drivers. It's clearly much, much easier when the same code base (and thus the same mdev type) is producing and consuming the migration data. Thanks, Alex