RE: [RFC PATCH 2/3] vfio/ims: Support emulated interrupts

[Tian, Kevin]

> From: Chatre, Reinette <reinette.chatre@xxxxxxxxx>
> Sent: Friday, August 25, 2023 1:19 AM
> 
> Hi Jason,
> 
> On 8/24/2023 9:33 AM, Jason Gunthorpe wrote:
> > On Thu, Aug 24, 2023 at 09:15:21AM -0700, Reinette Chatre wrote:
> >> Access from a guest to a virtual device may be either 'direct-path',
> >> where the guest interacts directly with the underlying hardware,
> >> or 'intercepted path' where the virtual device emulates operations.
> >>
> >> Support emulated interrupts that can be used to handle 'intercepted
> >> path' operations. For example, a virtual device may use 'intercepted
> >> path' for configuration. Doing so, configuration requests intercepted
> >> by the virtual device driver are handled within the virtual device
> >> driver with completion signaled to the guest without interacting with
> >> the underlying hardware.
> >
> > Why does this have anything to do with IMS? I thought the point here
> > was that IMS was some back end to the MSI-X emulation - should a
> > purely emulated interrupt logically be part of the MSI code, not IMS?
> 
> You are correct, an emulated interrupt is not unique to IMS.
> 
> The target usage of this library is by pure(?) VFIO devices (struct
> vfio_device). These are virtual devices that are composed by separate
> VFIO drivers. For example, a single resource of an accelerator device
> can be composed into a stand-alone virtual device for use by a guest.
> 
> Through its API and implementation the current VFIO MSI
> code expects to work with actual PCI devices (struct
> vfio_pci_core_device). With the target usage not being an
> actual PCI device the VFIO MSI code was not found to be a good
> fit and thus this implementation does not build on current MSI
> support.
> 

This might be achieved by creating a structure vfio_pci_intr_ctx
included by vfio_pci_core_device and other vfio device types. Then
move vfio_pci_intr.c to operate on vfio_pci_intr_ctx instead of
vfio_pci_core_device to make MSI frontend code sharable by both
PCI devices or virtual devices (mdev or SIOV).

Then there is only one irq_ctx. Within the ctx we can abstract
backend ops, e.g. enable/disble_msi(), alloc/free_ctx(), alloc/free_irq(), etc.
to accommodate pci MSI/MSI-X, IMS, or emulation.

The unknown risk is whether a clear abstraction can be defined. If
in the end the common library contains many if-else to handle subtle
backend differences then it might not be a good choice...