Linux 6.2 Brings A Big Rework To The MSI Subsystem
The IRQ pull request that was merged early in the Linux 6.2 cycle has a big rework to the Message Signaled Interrupts (MSI) subsystem.
Thomas Gleixner sent in the big MSI rework that he and other kernel developers have been tackling. He explained in the pull request this work around supporting per-device MSI interrupt domains and working toward support for the new Interrupt Message Store (IMS) specification.
The IDXD driver in reference is for the Intel Data Accelerator Driver as part of Intel Scalable IOV.
See the pull request for more details on this irq/core code that was merged for Linux 6.2.
Thomas Gleixner sent in the big MSI rework that he and other kernel developers have been tackling. He explained in the pull request this work around supporting per-device MSI interrupt domains and working toward support for the new Interrupt Message Store (IMS) specification.
The bulk is the rework of the MSI subsystem to support per device MSI interrupt domains. This solves conceptual problems of the current PCI/MSI design which are in the way of providing support for PCI/MSI[-X] and the upcoming PCI/IMS mechanism on the same device.
IMS (Interrupt Message Store] is a new specification which allows device manufactures to provide implementation defined storage for MSI messages contrary to the uniform and specification defined storage mechanisms for PCI/MSI and PCI/MSI-X. IMS not only allows to overcome the size limitations of the MSI-X table, but also gives the device manufacturer the freedom to store the message in arbitrary places, even in host memory which is shared with the device.
There have been several attempts to glue this into the current MSI code, but after lengthy discussions it turned out that there is a fundamental design problem in the current PCI/MSI-X implementation
...
In course of the lengthy discussions we identified other abuse of the MSI infrastructure in wireless drivers, NTB etc. where support for implementation specific message storage was just mindlessly glued into the existing infrastructure. Some of this just works by chance on particular platforms but will fail in hard to diagnose ways when the driver is used on platforms where the underlying MSI interrupt management code does not expect the creative abuse.
Another shortcoming of today's PCI/MSI-X support is the inability to allocate or free individual vectors after the initial enablement of MSI-X. This results in an works by chance implementation of VFIO (PCI pass-through) where interrupts on the host side are not set up upfront to avoid resource exhaustion. They are expanded at run-time when the guest actually tries to use them. The way how this is implemented is that the host disables MSI-X and then re-enables it with a larger number of vectors again. That works by chance because most device drivers set up all interrupts before the device actually will utilize them. But that's not universally true because some drivers allocate a large enough number of vectors but do not utilize them until it's actually required, e.g. for acceleration support. But at that point other interrupts of the device might be in active use and the MSI-X disable/enable dance can just result in losing interrupts and therefore hard to diagnose subtle problems.
Last but not least the "global" PCI/MSI-X domain approach prevents to utilize PCI/MSI[-X] and PCI/IMS on the same device due to the fact that IMS is not longer providing a uniform storage and configuration model.
The solution to this is to implement the missing step and switch from global PCI/MSI domains to per device PCI/MSI domains.
...
This work converts the MSI and PCI/MSI core and the x86 interrupt domains to the new model, provides new interfaces for post-enable allocation/free of MSI-X interrupts and the base framework for PCI/IMS. PCI/IMS has been verified with the work in progress IDXD driver.
There is work in progress to convert ARM over which will replace the platform MSI train-wreck. The cleanup of VFIO, NTB and other creative "solutions" are in the works as well.
The IDXD driver in reference is for the Intel Data Accelerator Driver as part of Intel Scalable IOV.
See the pull request for more details on this irq/core code that was merged for Linux 6.2.
7 Comments