On Wed, May 08, 2019 at 11:27:47PM +0800, Boris Fiuczynski wrote: > On 5/8/19 11:22 PM, Alex Williamson wrote: > >>> I thought there was a request to make this more specific to migration > >>> by renaming it to something like migration_version. Also, as an > >>> > >> so this attribute may not only include a mdev device's parent device info and > >> mdev type, but also include numeric software version of vendor specific > >> migration code, right? > > It's a vendor defined string, it should be considered opaque to the > > user, the vendor can include whatever they feel is relevant. > > > Would a vendor also be allowed to provide a string expressing required > features as well as containing backend resource requirements which need > to be compatible for a successful migration? Somehow a bit like a cpu > model... maybe even as json or xml... > I am asking this with vfio-ap in mind. In that context checking > compatibility of two vfio-ap mdev devices is not as simple as checking > if version A is smaller or equal to version B. > I think so. vendor driver is allowed to put whatever content into the migration_version string as long as it thinks it's necessary. vendor driver only needs ensure in the target mdev device, the write(2) operation on its migration_version attribute would correctly fail or succeeed based on the input string. Thanks Yan > -- > Mit freundlichen Grüßen/Kind regards > Boris Fiuczynski > > IBM Deutschland Research & Development GmbH > Vorsitzender des Aufsichtsrats: Matthias Hartmann > Geschäftsführung: Dirk Wittkopp > Sitz der Gesellschaft: Böblingen > Registergericht: Amtsgericht Stuttgart, HRB 243294 > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
