[for-9.0,v2,00/10] vfio: Introduce a VFIOIOMMUClass

Hello,

The VFIO object hierarchy has some constraints because each VFIO type
has a dual nature: a VFIO nature for passthrough support and a bus
nature (PCI, AP, CCW, Platform) for its initial presentation. It
seemed the best approach made because multi-inheritance is not
feasible with QOM and both aspect of the VFIO object, passthrough and
bus, require state. A QOM interface in that case is not sufficient.

One aspect of passthrough is interaction with the IOMMU. IOMMUFD
support was recently added and for this purpose, we introduced an
IOMMU backend framework simply based on a VFIOIOMMUOps struct. We
didn't want to use QOM again because it would have exposed the various
lowlevel backend objects to the QEMU machine and human interface which
felt unnecessary at the time.

The changes of this series introduce a VFIO_IOMMU QOM interface and
its VFIOIOMMUClass to replace the current VFIOIOMMUOps. This provides
better code abstraction for the type1 and sPAPR IOMMU backends and
allows us to improve the vfio_connect_container() implementation.
Also, QOM interfaces are not exposed at the QEMU interface level. Most
important, we can now avoid compiling the sPAPR IOMMU support on
targets not needing it. This saves some text in QEMU.

Applies on vfio-next.

Thanks,

C.

Changes in v2:
 - Removed superfluous define and struct definitions
 - Improved comments and commit log
 - Removed NULL initialization of vioc
 - Removed class_size initialization

Cédric Le Goater (10):
  vfio/spapr: Extend VFIOIOMMUOps with a release handler
  vfio/container: Introduce vfio_legacy_setup() for further cleanups
  vfio/container: Initialize VFIOIOMMUOps under vfio_init_container()
  vfio/container: Introduce a VFIOIOMMU QOM interface
  vfio/container: Introduce a VFIOIOMMU legacy QOM interface
  vfio/container: Intoduce a new VFIOIOMMUClass::setup handler
  vfio/spapr: Introduce a sPAPR VFIOIOMMU QOM interface
  vfio/iommufd: Introduce a VFIOIOMMU iommufd QOM interface
  vfio/spapr: Only compile sPAPR IOMMU support when needed
  vfio/iommufd: Remove CONFIG_IOMMUFD usage

 include/hw/vfio/vfio-common.h         |   2 -
 include/hw/vfio/vfio-container-base.h |  27 ++++-
 hw/vfio/common.c                      |  11 +-
 hw/vfio/container-base.c              |  12 ++-
 hw/vfio/container.c                   | 146 ++++++++++++++++----------
 hw/vfio/iommufd.c                     |  35 ++++--
 hw/vfio/pci.c                         |   2 +-
 hw/vfio/spapr.c                       |  60 ++++++-----
 hw/vfio/meson.build                   |   2 +-
 9 files changed, 197 insertions(+), 100 deletions(-)

On 12/19/23 07:58, Cédric Le Goater wrote:
> Hello,
> 
> The VFIO object hierarchy has some constraints because each VFIO type
> has a dual nature: a VFIO nature for passthrough support and a bus
> nature (PCI, AP, CCW, Platform) for its initial presentation. It
> seemed the best approach made because multi-inheritance is not
> feasible with QOM and both aspect of the VFIO object, passthrough and
> bus, require state. A QOM interface in that case is not sufficient.
> 
> One aspect of passthrough is interaction with the IOMMU. IOMMUFD
> support was recently added and for this purpose, we introduced an
> IOMMU backend framework simply based on a VFIOIOMMUOps struct. We
> didn't want to use QOM again because it would have exposed the various
> lowlevel backend objects to the QEMU machine and human interface which
> felt unnecessary at the time.
> 
> The changes of this series introduce a VFIO_IOMMU QOM interface and
> its VFIOIOMMUClass to replace the current VFIOIOMMUOps. This provides
> better code abstraction for the type1 and sPAPR IOMMU backends and
> allows us to improve the vfio_connect_container() implementation.
> Also, QOM interfaces are not exposed at the QEMU interface level. Most
> important, we can now avoid compiling the sPAPR IOMMU support on
> targets not needing it. This saves some text in QEMU.


Applied to vfio-next.

Thanks,

C.

On Tue, 2023-12-19 at 07:58 +0100, Cédric Le Goater wrote:
> Hello,
> 
> The VFIO object hierarchy has some constraints because each VFIO type
> has a dual nature: a VFIO nature for passthrough support and a bus
> nature (PCI, AP, CCW, Platform) for its initial presentation.

The above caught my attention, so I kicked the tires on this series a
little bit both with an iommufd-enabled host kernel and without, so I
don't lose track of it over the holidays.

Tested-by: Eric Farman <farman@linux.ibm.com>

On 12/20/23 21:35, Eric Farman wrote:
> On Tue, 2023-12-19 at 07:58 +0100, Cédric Le Goater wrote:
>> Hello,
>>
>> The VFIO object hierarchy has some constraints because each VFIO type
>> has a dual nature: a VFIO nature for passthrough support and a bus
>> nature (PCI, AP, CCW, Platform) for its initial presentation.
> 
> The above caught my attention, so I kicked the tires on this series a
> little bit both with an iommufd-enabled host kernel and without, so I
> don't lose track of it over the holidays.

I don't plan to send a vfio PR in the current weeks. iommufd support is
upstream and still very warm and we should let it cool down during the
holidays.

> Tested-by: Eric Farman <farman@linux.ibm.com>

Thanks !

C.