activer / désactiver les interruptions PCI

J'implémente un pilote PCIe et j'aimerais comprendre à quel niveau les interruptions peuvent ou doivent être activées / désactivées. Je ne précise pas intentionnellement le système d'exploitation, car je suppose qu'il devrait être pertinent pour n'importe quelle plate-forme. Par niveaux, j'entends ce qui suit:

Cadre de gestion des interruptions spécifiques au système d'exploitation
Les interruptions peuvent être désactivées ou activées dans les registres d'espace de configuration PCI / PCIe, par exemple le registre COMMAND
Les interruptions peuvent également être masquées au niveau du périphérique, par exemple, nous pouvons configurer le périphérique pour ne pas déclencher certaines interruptions vers l'hôte

Je comprends que quel que soit le type d'interruption utilisé sur PCIe (émulation INTx, MSI ou MSI-X), il doit être livré au système d'exploitation hôte.

Ma question est donc la suivante: devons-nous réellement activer ou désactiver les interruptions sur chaque couche, ou est-ce suffisant uniquement au plus proche du matériel, par exemple dans les registres PCI pertinents?

interrupts bus pcie

— marque
source

Dans les pilotes KMDF Windows, vous spécifiez dans le fichier .inf du pilote le type d'interruptions à utiliser (MSI vs INTx vs MSI-x) et la structure du pilote configurera correctement l'espace de configuration PCIe lui-même lors du chargement. Je ne connais pas les autres systèmes d'exploitation, mais comme les fichiers .inf sont spécifiques à Windows, je pense que cela dépend probablement du système d'exploitation.

— Tom Carpenter

Vous devez généralement les activer complètement en fournissant une configuration pour ce qui doit être fait avec l'interruption. Une fois cela fait, la désactivation se fait sur le processeur uniquement pendant de brèves périodes de calcul sans interruption, jusqu'à ce que vous déconfigurez le périphérique (par exemple pour économiser l'énergie)

— pjc50

SI vous utilisez linux, pourriez-vous utiliser le framework DMA pour votre application? C'est très bien, vous créez la transaction, et elle revient avec un délai facultatif lorsque la transaction est terminée - vous n'avez pas à vous tromper avec l'interruption réelle

— johnnymopo

@ pjc50, si un pilote choisit d'utiliser un certain type d'interruptions, par exemple INTx, doit-il désactiver la livraison des interruptions MSI / MSI-X via les registres pci MSI_CAP? (Et l'inverse - désactiver INTx lors de l'utilisation de MSI)

— Mark

Les systèmes d'exploitation se plaignent généralement fortement des interruptions inattendues, car il s'agit d'erreurs de programmation facilement détectables dans les pilotes.

En règle générale, votre matériel démarre dans un état assez inerte après la réinitialisation, où il attend d'être configuré. Dans cet état, il n'existe aucun moyen significatif de générer une interruption, car aucun mappage n'est encore établi et vous ne savez pas quelle interruption.

Pendant la configuration, le mappage d'interruption existe et la carte est informée de la ligne d'interruption à utiliser (INTA..INTD en tant que PCI hérité, ou MSI / MSI-X), mais il n'y a toujours pas de pilote pour gérer les interruptions. Linux a un gestionnaire par défaut ici qui se plaint du journal système et désactive ensuite la source d'interruption, car le matériel semble être défectueux (c'est-à-dire que par défaut, toutes les interruptions sont activées, mais seules celles où un gestionnaire est enregistré devraient réellement se produire) .

Le pilote enregistre enfin les gestionnaires d'interruptions et active les interruptions qui l'intéressent. Si le pilote n'est plus intéressé par une condition spécifique, il doit désactiver l'interruption dans le périphérique, car c'est là que les causes d'interruption spécifiques au périphérique sont masquées - les couches inférieures savent seulement que "quelque chose est arrivé".

— Simon Richter
source