Re: [PATCH 2/3] vfio/mdev: inline needed class_compat functionality

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

On Wed, 11 Dec 2024 20:42:06 -0800
Christoph Hellwig <hch@infradead.org> wrote:
> On Sat, Dec 07, 2024 at 11:06:15AM +0100, Heiner Kallweit wrote:
> > Issue with this approach is that these "mdev parent" devices are partially
> > class devices belonging to other classes. See for example mtty_dev_init(),
> > there the device passed to us belongs to class mtty.  
> 
> The samples don't matter and can be fixed any time.  Or even better
> deleted.

There is value to these.  In particular mtty exposes a dummy PCI serial
device with two different flavors (single/dual port) that's useful for
not only testing the mdev lifecycle behavior, but also implements the
vfio migration API.  Otherwise testing any of this requires specific
hardware.  I'd agree that breaking userspace API for a sample device is
less of a blocking issue, but then we have these...

> The real question is if the i915, ccw and ap devices are
> class devices.  From a quick unscientific grep they appear not to,
> but we'd need to double check that.

And I'd expect that these are all linking bus devices under the
mdev_bus class.  I understand the issue now, that from the start we
should have been creating class devices, but it seems that resolving
that is going to introduce a level of indirection between the new class
device and the bus device which is likely going to have dependencies in
the existing userspace tools.  We'll need to work through the primary
ones and figure out contingencies for the others to avoid breaking
userspace.  The "just remove it anyway" stance seems to be in conflict
with the "don't break userspace" policy and I don't think we can
instantly fix this.  Thanks,

Alex