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

Alex Williamson
2019-05-29T14:09:03Z

On Tue, 28 May 2019 22:57:15 +0200
Boris Fiuczynski <fiuczy@linux.ibm.com> wrote:

> On 5/14/19 5:31 PM, Alex Williamson wrote:
> > On Wed, 8 May 2019 17:27:47 +0200
> > Boris Fiuczynski <fiuczy@linux.ibm.com> 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@redhat.com
> > https://www.redhat.com/mailman/listinfo/libvir-list
> >
>
>