El pull request IRQ que fue fusionado a principios del ciclo Linux 6.2 tiene una gran revisión del subsistema Message Signaled Interrupts (MSI).
Thomas Gleixner envió la gran revisión de MSI que él y otros desarrolladores del núcleo han estado abordando. Explicó en el pull request este trabajo en torno al soporte de dominios de interrupción MSI por dispositivo y trabajando hacia el soporte de la nueva especificación Interrupt Message Store (IMS).
Puede leer más | Linux 6.1 disponible con la infraestructura de Rust
El grueso es la revisión del subsistema MSI para soportar dominios de interrupción MSI por dispositivo. Esto resuelve los problemas conceptuales del actual diseño PCI/MSI que impiden ofrecer soporte para PCI/MSI[-X] y el próximo mecanismo PCI/IMS en el mismo dispositivo.
IMS (Interrupt Message Store] es una nueva especificación que permite a los fabricantes de dispositivos proporcionar un almacenamiento definido por la implementación para los mensajes MSI, al contrario que los mecanismos de almacenamiento uniformes y definidos por la especificación para PCI/MSI y PCI/MSI-X. IMS no sólo permite superar las limitaciones de tamaño de la tabla MSI-X, sino que también da al fabricante del dispositivo la libertad de almacenar el mensaje en lugares arbitrarios, incluso en la memoria del host que se comparte con el dispositivo.
Puede Leer más | Núcleo Linux 6.1: La versión Rust para el desarrollo del Kernel de Linux
Ha habido varios intentos de pegar esto en el código MSI actual, pero después de largas discusiones resultó que hay un problema de diseño fundamental en la implementación PCI/MSI-X actual ...
En el transcurso de las largas discusiones identificamos otros abusos de la infraestructura MSI en controladores inalámbricos, NTB etc. donde el soporte para el almacenamiento de mensajes específicos de la implementación fue simplemente pegado sin sentido en la infraestructura existente. Algo de esto funciona por casualidad en plataformas particulares pero fallará de forma difícil de diagnosticar cuando el driver se use en plataformas donde el código de gestión de interrupciones MSI subyacente no espera el abuso creativo.
Puede leer más | KaOS 2022.12 disponible con Kernel Linux 6.0
Otra deficiencia del soporte PCI/MSI-X actual es la incapacidad de asignar o liberar vectores individuales después de la habilitación inicial de MSI-X. Esto resulta en una implementación de VFIO (PCI pass-through) en la que las interrupciones en el lado del host no se configuran por adelantado para evitar el agotamiento de recursos. Se expanden en tiempo de ejecución cuando el huésped realmente intenta utilizarlas. La forma en que esto se implementa es que el host desactiva MSI-X y luego lo vuelve a activar con un mayor número de vectores de nuevo. Eso funciona por casualidad porque la mayoría de los controladores de dispositivo configuran todas las interrupciones antes de que el dispositivo realmente las utilice. Pero eso no es universalmente cierto porque algunos controladores asignan un número suficientemente grande de vectores pero no los utilizan hasta que es realmente necesario, por ejemplo para soporte de aceleración. Pero en ese momento otras interrupciones del dispositivo pueden estar en uso activo y el baile de desactivar/activar de MSI-X puede sólo resultar en la pérdida de interrupciones y por lo tanto en problemas sutiles difíciles de diagnosticar.
Puede leer más | Disponible el Kernel Linux 6.0 y Linus Torvalds promete novedades
Por último, pero no menos importante, el enfoque de dominio PCI/MSI-X "global" impide utilizar PCI/MSI[-X] y PCI/IMS en el mismo dispositivo debido a que IMS ya no proporciona un modelo uniforme de almacenamiento y configuración.
La solución a esto es implementar el paso que falta y cambiar de dominios PCI/MSI globales a dominios PCI/MSI por dispositivo.
Este trabajo convierte el núcleo MSI y PCI/MSI y los dominios de interrupción x86 al nuevo modelo, proporciona nuevas interfaces para la asignación/liberación posterior a la activación de las interrupciones MSI-X y el marco base para PCI/IMS. PCI/IMS se ha verificado con el controlador IDXD en curso.
Hay trabajo en curso para convertir ARM sobre que sustituirá a la plataforma MSI tren-desastre. También se está trabajando en la limpieza de VFIO, NTB y otras "soluciones" creativas.
El controlador IDXD en referencia es para el Intel Data Accelerator Driver como parte de Intel Scalable IOV.
Vea el pull request para más detalles sobre este código irq/core que fue fusionado para Linux 6.2.