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

[Boris Fiuczynski]

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.
Using the migrations_version as some kind of configuration transport 
and/or reservation mechanism wasn't my intention and IMHO would both be 
wrong.

> 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


--
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