Re: device compatibility interface for live migration with assigned devices

[Cornelia Huck <cohuck@redhat.com>]

On Fri, 7 Aug 2020 13:59:42 +0200
Cornelia Huck <cohuck@redhat.com> wrote:

> On Wed, 05 Aug 2020 12:35:01 +0100
> Sean Mooney <smooney@redhat.com> wrote:
> 
> > On Wed, 2020-08-05 at 12:53 +0200, Jiri Pirko wrote:  
> > > Wed, Aug 05, 2020 at 11:33:38AM CEST, yan.y.zhao@intel.com wrote:    
> 
> (...)
> 
> > > >    software_version: device driver's version.
> > > >               in <major>.<minor>[.bugfix] scheme, where there is no
> > > > 	       compatibility across major versions, minor versions have
> > > > 	       forward compatibility (ex. 1-> 2 is ok, 2 -> 1 is not) and
> > > > 	       bugfix version number indicates some degree of internal
> > > > 	       improvement that is not visible to the user in terms of
> > > > 	       features or compatibility,
> > > > 
> > > > vendor specific attributes: each vendor may define different attributes
> > > >   device id : device id of a physical devices or mdev's parent pci device.
> > > >               it could be equal to pci id for pci devices
> > > >   aggregator: used together with mdev_type. e.g. aggregator=2 together
> > > >               with i915-GVTg_V5_4 means 2*1/4=1/2 of a gen9 Intel
> > > > 	       graphics device.
> > > >   remote_url: for a local NVMe VF, it may be configured with a remote
> > > >               url of a remote storage and all data is stored in the
> > > > 	       remote side specified by the remote url.
> > > >   ...    
> > just a minor not that i find ^ much more simmple to understand then
> > the current proposal with self and compatiable.
> > if i have well defiend attibute that i can parse and understand that allow
> > me to calulate the what is and is not compatible that is likely going to
> > more useful as you wont have to keep maintianing a list of other compatible
> > devices every time a new sku is released.
> > 
> > in anycase thank for actully shareing ^ as it make it simpler to reson about what
> > you have previously proposed.  
> 
> So, what would be the most helpful format? A 'software_version' field
> that follows the conventions outlined above, and other (possibly
> optional) fields that have to match?

Just to get a different perspective, I've been trying to come up with
what would be useful for a very different kind of device, namely
vfio-ccw. (Adding Eric to cc: for that.)

software_version makes sense for everybody, so it should be a standard
attribute.

For the vfio-ccw type, we have only one vendor driver (vfio-ccw_IO).

Given a subchannel A, we want to make sure that subchannel B has a
reasonable chance of being compatible. I guess that means:

- same subchannel type (I/O)
- same chpid type (e.g. all FICON; I assume there are no 'mixed' setups
  -- Eric?)
- same number of chpids? Maybe we can live without that and just inject
  some machine checks, I don't know. Same chpid numbers is something we
  cannot guarantee, especially if we want to migrate cross-CEC (to
  another machine.)

Other possibly interesting information is not available at the
subchannel level (vfio-ccw is a subchannel driver.)

So, looking at a concrete subchannel on one of my machines, it would
look something like the following:

<common>
software_version=1.0.0
type=vfio-ccw          <-- would be vfio-pci on the example above
<vfio-ccw specific>
subchannel_type=0
<vfio-ccw_IO specific>
chpid_type=0x1a
chpid_mask=0xf0        <-- not sure if needed/wanted

Does that make sense?