Re: [libvirt] [PATCH 1/2] vfio/mdev: add version field as mandatory attribute for mdev device

On Tue, Apr 23, 2019 at 09:21:00AM +0800, Alex Williamson wrote: > On Mon, 22 Apr 2019 21:01:52 -0400 > Yan Zhao <yan.y.zhao(a)intel.com&gt; wrote: > > > On Mon, Apr 22, 2019 at 10:39:50PM +0800, Alex Williamson wrote: > > > On Fri, 19 Apr 2019 04:35:04 -0400 > > > Yan Zhao <yan.y.zhao(a)intel.com&gt; wrote: > > > > > > > device version attribute in mdev sysfs is used by user space software > > > > (e.g. libvirt) to query device compatibility for live migration of VFIO > > > > mdev devices. This attribute is mandatory if a mdev device supports live > > > > migration. > > > > > > The Subject: doesn't quite match what's being proposed here. > > > > > > > It consists of two parts: common part and vendor proprietary part. > > > > common part: 32 bit. lower 16 bits is vendor id and higher 16 bits > > > > identifies device type. e.g., for pci device, it is > > > > "pci vendor id" | (VFIO_DEVICE_FLAGS_PCI << 16). > > > > > > What purpose does this serve? If it's intended as some sort of > > > namespace feature, shouldn't we first assume that we can only support > > > migration to devices of the same type? Therefore each type would > > > already have its own namespace. Also that would make the trailing bit > > > of the version string listed below in the example redundant. A vendor > > > is still welcome to include this in their version string if they wish, > > > but I think the string should be entirely vendor defined. > > > > > hi Alex, > > This common part is a kind of namespace. > > Because if version string is entirely defined by vendors, I'm worried about > > if there is a case that one vendor's version string happens to deceive and > > interfere with another vendor's version checking? > > e.g. > > vendor A has a version string like: vendor id + device id + mdev type > > vendor B has a version string like: device id + vendor id + mdev type > > but vendor A's vendor id is 0x8086, device id is 0x1217 > > vendor B's vendor id is 0x1217, device id is 0x8086. > > > > In this corner case, the two vendors may regard the two device is > > migratable but actually they are not. > > > > That's the reason for this common part that serve as a kind of namespace > > that all vendors will comply with to avoid overlap. > > If we assume that migration can only occur between matching mdev types, > this is redundant, each type already has their own namespace. > hi Alex, do you mean user space software like libvirt needs to first check whether mdev type is matching and then check whether version is matching? if user space software only checks version for migration, it means vendor driver has to include mdev type in their vendor proprietary part string, right?

Another thing is that could there be any future mdev parent driver that applies to all mdev devices, just like vfio-pci? like Yi's vfio-pci-mdev driver (https://lkml.org/lkml/2019/3/13/114)?