device compatibility interface for live migration with assigned devices

[Alex Williamson]

On Thu, 10 Sep 2020 13:50:11 +0100
Sean Mooney <smooney at redhat.com> wrote:

> On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote:
> > On Wed, 9 Sep 2020 10:13:09 +0800
> > Yan Zhao <yan.y.zhao at intel.com> wrote:
> >   
> > > > > still, I'd like to put it more explicitly to make ensure it's not missed:
> > > > > the reason we want to specify compatible_type as a trait and check
> > > > > whether target compatible_type is the superset of source
> > > > > compatible_type is for the consideration of backward compatibility.
> > > > > e.g.
> > > > > an old generation device may have a mdev type xxx-v4-yyy, while a newer
> > > > > generation  device may be of mdev type xxx-v5-yyy.
> > > > > with the compatible_type traits, the old generation device is still
> > > > > able to be regarded as compatible to newer generation device even their
> > > > > mdev types are not equal.    
> > > > 
> > > > If you want to support migration from v4 to v5, can't the (presumably
> > > > newer) driver that supports v5 simply register the v4 type as well, so
> > > > that the mdev can be created as v4? (Just like QEMU versioned machine
> > > > types work.)    
> > > 
> > > yes, it should work in some conditions.
> > > but it may not be that good in some cases when v5 and v4 in the name string
> > > of mdev type identify hardware generation (e.g. v4 for gen8, and v5 for
> > > gen9)
> > > 
> > > e.g.
> > > (1). when src mdev type is v4 and target mdev type is v5 as
> > > software does not support it initially, and v4 and v5 identify hardware
> > > differences.  
> > 
> > My first hunch here is: Don't introduce types that may be compatible
> > later. Either make them compatible, or make them distinct by design,
> > and possibly add a different, compatible type later.
> >   
> > > then after software upgrade, v5 is now compatible to v4, should the
> > > software now downgrade mdev type from v5 to v4?
> > > not sure if moving hardware generation info into a separate attribute
> > > from mdev type name is better. e.g. remove v4, v5 in mdev type, while use
> > > compatible_pci_ids to identify compatibility.  
> > 
> > If the generations are compatible, don't mention it in the mdev type.
> > If they aren't, use distinct types, so that management software doesn't
> > have to guess. At least that would be my naive approach here.  
> yep that is what i would prefer to see too.
> >   
> > > 
> > > (2) name string of mdev type is composed by "driver_name + type_name".
> > > in some devices, e.g. qat, different generations of devices are binding to
> > > drivers of different names, e.g. "qat-v4", "qat-v5".
> > > then though type_name is equal, mdev type is not equal. e.g.
> > > "qat-v4-type1", "qat-v5-type1".  
> > 
> > I guess that shows a shortcoming of that "driver_name + type_name"
> > approach? Or maybe I'm just confused.  
> yes i really dont like haveing the version in the mdev-type name 
> i would stongly perfger just qat-type-1 wehere qat is just there as a way of namespacing.
> although symmetric-cryto, asymmetric-cryto and compression woudl be a better name then type-1, type-2, type-3 if
> that is what they would end up mapping too. e.g. qat-compression or qat-aes is a much better name then type-1
> higher layers of software are unlikely to parse the mdev names but as a human looking at them its much eaiser to
> understand if the names are meaningful. the qat prefix i think is important however to make sure that your mdev-types
> dont colide with other vendeors mdev types. so i woudl encurage all vendors to prefix there mdev types with etiher the
> device name or the vendor.

+1 to all this, the mdev type is meant to indicate a software
compatible interface, if different hardware versions can be software
compatible, then don't make the job of finding a compatible device
harder.  The full type is a combination of the vendor driver name plus
the vendor provided type name specifically in order to provide a type
namespace per vendor driver.  That's done at the mdev core level.
Thanks,

Alex