Re: [PATCH v3 0/2] VFIO mdev aggregated resources handling

[Alex Williamson <alex.williamson@redhat.com>]

On Thu, 9 Jul 2020 15:23:34 +0800
Yan Zhao <yan.y.zhao@intel.com> wrote:

> On Thu, Jul 09, 2020 at 02:53:05AM +0000, Tian, Kevin wrote:
> 
> <...>
> > > We also can't even seem to agree that type is a necessary requirement
> > > for compatibility.  Your discussion below of a type-A, which is
> > > equivalent to a type-B w/ aggregation set to some value is an example
> > > of this.  We might also have physical devices with extensions to
> > > support migration.  These could possibly be compatible with full mdev
> > > devices.  We have no idea how an administrative tool would discover
> > > this other than an exhaustive search across every possible target.
> > > That's ugly but feasible when considering a single target host, but
> > > completely untenable when considering a datacenter.  
> > 
> > If exhaustive search can be done just one-off to build the compatibility
> > database for all assignable devices on each node, then it might be
> > still tenable in datacenter?  
> yes, Alex, do you think below behavior to build compatibility database is
> acceptable?
> 
> management stack could do the exhaustive search in one shot to build the
> compatibility database for all devices in every node. Meanwhile, it caches
> migration version strings for all tested devices.
> when there's a newly created/attached device, management stack could write
> every cached strings to migration version attribute of the newly
> created/attached device in order to update the migration compatibility
> database. Then it caches the migration version string of the newly
> created/attached device as well.
> once a device attribute is modified, e.g. after changing its aggregation
> count or updating its parent driver, update its cached migration version
> string and update the compatibility database by testing against migration
> version attribute of this device.

This is exactly the scenario that I think is untenable.  You're asking
a management application to keep a live database of the opaque version
string of every device type and likely every instance of a device,
which it's not allowed to compare on its own, it can only pipe them
through to every other device across the datacenter to determine which
are comparable.  It would need to respond to not only devices being
added and removed, but bound and unbound from drivers, and entire nodes
being added and removed.  That seems like a lot of overhead, in
addition to the effect of essentially fuzzing the version interface
across all vendors and types.  We need a better solution or we need
someone from openstack and ovirt to agree that this is more viable than
I suspect. Thanks,

Alex