> 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...
