On Tue, 28 May 2019 22:57:15 +0200 Boris Fiuczynski <fiuczy@xxxxxxxxxxxxx> wrote: > On 5/14/19 5:31 PM, Alex Williamson wrote: > > On Wed, 8 May 2019 17:27:47 +0200 > > Boris Fiuczynski <fiuczy@xxxxxxxxxxxxx> 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. > > > > Two pieces to this, the first is that the string is opaque exactly so > > that the vendor driver can express whatever they need in it. The user > > should never infer that two devices are compatible. The second is that > I agree. > > > this is not a resource availability or reservation interface. The fact > I also agree. The migration_version (version in this case is not really > a good fit) is a summary of requirements the source mdev has which a > target mdev needs to be able to fulfill in order to allow migration. > The target mdev already exists and was already configured by other means > not involved in the migration check process. Just a nit here (I hope), the target mdev does not necessarily exist at the time we're testing migration version compatibility. The intention is that this feature can be used to select a target host system which can possibly generate a compatible target mdev device before committing to create that device. For instance a management tool might test for migration compatibility across a data center, narrowing the set of potential target hosts, then proceed to select a best choice based on factors including the ability to actually instantiate such a device on the host. > Using the migrations_version as some kind of configuration transport > and/or reservation mechanism wasn't my intention and IMHO would both be > wrong. Sounds good. Thanks, Alex > > that a target device would be compatible for migration should not take > > into account whether the target has the resources to actually create > > such a device. Doing so would imply some sort of resource reservation > > support that does not exist. Matrix devices are clearly a bit > > complicated here since maybe the source is expressing a component of > > the device that doesn't exist on the target. In such a "resource not > > available at all" case, it might be fair to nak the compatibility test, > > but a "ok, but resource not currently available" case should pass, > > imo. Thanks, > > > > Alex > > > > -- > > libvir-list mailing list > > libvir-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/libvir-list > > > >
