On Tue, Apr 23, 2019 at 06:24:19PM +0800, Daniel P. Berrangé wrote: > On Tue, Apr 23, 2019 at 01:41:57AM -0400, Yan Zhao wrote: > > 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@xxxxxxxxx> 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@xxxxxxxxx> 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? > > I would expect that libvirt (or other mgmt apps) will always first > check that the vendor id, device id, mdev type all match. So for the > version string it should suffice to be a "normal" numeric value. > > Essentially version string just needs to be there to distinguish > revisions of the same mdev type over time. > hi Daniel, The way that user space software checks that the vendor id, device id, mdev type all match and version string is just revisions is somewhat restrictive? user space software could not have so much detailed information regarding to which devices are compatible, especially when vendor id, device id, revision id, and mdev types are not enough or no need to be exactly the same. By moving decision making for compatibility from user space to vendor driver, user space software can be more change-resistant. Agree? Thanks Yan > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
