On Tue, Apr 23, 2019 at 11:39:39AM +0100, Daniel P. Berrangé wrote: > On Fri, Apr 19, 2019 at 04:35:04AM -0400, Yan Zhao 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. > > > > 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). > > vendor proprietary part: this part is varied in length. vendor driver can > > specify any string to identify a device. > > > > When reading this attribute, it should show device version string of the > > device of type <type-id>. If a device does not support live migration, it > > should return errno. > > When writing a string to this attribute, it returns errno for > > incompatibility or returns written string length in compatibility case. > > If a device does not support live migration, it always returns errno. > > > > For user space software to use: > > 1. > > Before starting live migration, user space software first reads source side > > mdev device's version. e.g. > > "#cat \ > > /sys/bus/pci/devices/0000\:00\:02.0/5ac1fb20-2bbf-4842-bb7e-36c58c3be9cd/mdev_type/version" > > 00028086-193b-i915-GVTg_V5_4 > > > > 2. > > Then, user space software writes the source side returned version string > > to device version attribute in target side, and checks the return value. > > If a negative errno is returned in the target side, then mdev devices in > > source and target sides are not compatible; > > If a positive number is returned and it equals to the length of written > > string, then the two mdev devices in source and target side are compatible. > > e.g. > > (a) compatibility case > > "# echo 00028086-193b-i915-GVTg_V5_4 > > > /sys/bus/pci/devices/0000\:00\:02.0/882cc4da-dede-11e7-9180-078a62063ab1/mdev_type/version" > > > > (b) incompatibility case > > "#echo 00028086-193b-i915-GVTg_V5_1 > > > /sys/bus/pci/devices/0000\:00\:02.0/882cc4da-dede-11e7-9180-078a62063ab1/mdev_type/version" > > -bash: echo: write error: Invalid argument > > What you have written here seems to imply that each mdev type is able to > support many different versions at the same time. Writing a version into > this sysfs file then chooses which of the many versions to actually use. > > This is good as it allows for live migration across driver software upgrades. > > A mgmt application may well want to know what versions are supported for an > mdev type *before* starting a migration. A mgmt app can query all the 100's > of hosts it knows and thus figure out which are valid to use as the target > of a migration. > > IOW, we want to avoid the ever hitting the incompatibility case in the > first place, by only choosing to migrate to a host that we know is going > to be compatible. > > This would need some kind of way to report the full list of supported > versions against the mdev supported types on the host. What would be the typical scenario / use case for mgmt layer to query the version information? Do they expect this get done completely offline as long as the vendor driver installed on each host? Thanks, Neo > > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
