MINIPORT_MESSAGE_INTERRUPT fonction de rappel (ndis.h)

Article
08/07/2023

NDIS appelle la fonction MiniportMessageInterrupt lorsqu’une carte réseau génère une interruption basée sur les messages.

Note Vous devez déclarer la fonction à l’aide du type MINIPORT_MESSAGE_INTERRUPT . Pour plus d’informations, consultez la section Exemples suivante.

Syntaxe

MINIPORT_MESSAGE_INTERRUPT MiniportMessageInterrupt;

BOOLEAN MiniportMessageInterrupt(
  [in]  NDIS_HANDLE MiniportInterruptContext,
  [in]  ULONG MessageId,
  [out] PBOOLEAN QueueDefaultInterruptDpc,
  [out] PULONG TargetProcessors
)
{...}

Paramètres

[in] MiniportInterruptContext

Handle pour un bloc d’informations de contexte d’interruption. Le pilote miniport a fourni cette poignée dans le paramètre MiniportInterruptContext que le pilote miniport a transmis au Fonction NdisMRegisterInterruptEx .

[in] MessageId

Identificateur de message d’interruption signalée par message (MSI). MessageId est un index d’un IO_INTERRUPT_MESSAGE_INFO_ENTRY structure à l’intérieur d’un IO_INTERRUPT_MESSAGE_INFO structure. NDIS transmet un pointeur à la structure IO_INTERRUPT_MESSAGE_INFO associée au membre MessageInfoTable lorsque le pilote s’inscrit correctement pour MSI avec la fonction NdisMRegisterInterruptEx .

[out] QueueDefaultInterruptDpc

Pointeur vers une variable booléenne que le pilote miniport définit avant de revenir à partir de cet appel. Un pilote miniport définit cette valeur sur TRUE pour indiquer que le pilote nécessite un DPC sur le processeur (actuel) par défaut. Si la valeur est TRUE, NDIS ignore la valeur du paramètre TargetProcessors . Si la valeur est FALSE, NDIS utilise la valeur du paramètre TargetProcessors pour planifier les contrôleurs de base de données.

[out] TargetProcessors

Masque de bits qui indique les processeurs cibles pour lesquels NDIS doit planifier un DPC. Ce masque de bits représente les 32 premiers processeurs du groupe de processeurs 0. Chaque bit dans le masque de bits identifie un processeur. Si l’appelant définit le bit 0, NDIS planifie un DPC pour le processeur 0. Si l’appelant définit le bit 1, NDIS planifie un DPC pour le processeur 1, et ainsi de suite.

Note Les pilotes NDIS 6.20 et versions ultérieures ne doivent pas utiliser ce paramètre pour planifier des contrôleurs de domaine. Au lieu de cela, ils doivent définir ce paramètre sur zéro et utiliser la fonction NdisMQueueDpcEx pour planifier les DCP.

Valeur retournée

MiniportMessageInterrupt retourne TRUE si la carte réseau sous-jacente a généré l’interruption ; sinon, elle retourne FALSE.

Remarques

Les pilotes Miniport qui s’inscrivent à la prise en charge des interruptions signalées par message (MSI) avec la fonction NdisMRegisterInterruptEx doivent fournir une fonction MiniportMessageInterrupt .

Un pilote miniport doit faire le moins de travail possible dans sa fonction MiniportMessageInterrupt . Il doit différer les opérations d’E/S pour les interruptions générées par la carte réseau Fonction MiniportMessageInterruptDPC .

Lorsqu’une carte réseau génère une msi, NDIS appelle la fonction MiniportMessageInterrupt du pilote miniport.

MiniportMessageInterrupt enregistre les informations d’état requises sur l’interruption et reporte autant que possible le traitement des E/S au Fonction MiniportMessageInterruptDPC .

Si le pilote miniport demande des appels de procédure différée (DPC) pour un message spécifié, le pilote miniport doit désactiver toutes les interruptions supplémentaires pour ce message et réactiver les interruptions une fois toutes les DPC terminées.

Le pilote miniport doit définir QueueDefaultInterruptDpc sur TRUE pour planifier un DPC pour le processeur par défaut uniquement. Le pilote peut effectuer cette opération, par exemple dans les cas suivants :

La carte réseau a généré l’interruption pour signaler l’achèvement d’une opération d’envoi ou de toute autre requête qui ne s’exécute pas sur d’autres processeurs.
La carte réseau a généré l’interruption pour signaler les données reçues et le pilote miniport ne peut pas traiter les paquets reçus dans des DPC distincts.
L’interruption indique les paquets reçus et le pilote miniport peut traiter les paquets reçus dans des contrôleurs de domaine distincts, mais la mise à l’échelle côté réception (RSS) n’est pas activée pour le pilote miniport. Pour plus d'informations, consultez la rubrique OID_GEN_RECEIVE_SCALE_CAPABILITIES et OID_GEN_RECEIVE_SCALE_PARAMETERS.
La mise à l’échelle côté réception est activée pour le pilote miniport, et le pilote miniport peut générer différents messages sur chaque file d’attente de réception.

Si un pilote miniport traite les paquets reçus dans des DCP distincts, le pilote miniport définit le paramètre QueueDefaultInterruptDpc sur FALSE. Le pilote miniport doit définir le bit TargetProcessors pour le processeur associé à chaque file d’attente de réception non vide. NDIS planifie un DPC sur chacun des processeurs indiqués dans le groupe de processeurs 0.

Si MiniportMessageInterrupt partage des ressources pour un message spécifié, par exemple des registres de carte réseau ou des variables d’état, avec une autre fonction MiniportXxx qui s’exécute à un IRQL inférieur, cette fonction MiniportXxx doit appeler le NdisMSynchronizeWithInterruptEx , fonction. Cela garantit que la fonction MiniportSynchronizeMessageInterrupt du pilote accède aux ressources partagées de manière synchronisée et multiprocesseur sécurisée.

Un pilote miniport peut appeler le Fonction NdisMDeregisterInterruptEx à partir de sa fonction MiniportInitializeEx ou MiniportHaltEx pour libérer les ressources qu’elle a allouées avec NdisMRegisterInterruptEx. Une fois que NdisMDeregisterInterruptEx est retourné, NDIS n’appelle pas la fonction MiniportMessageInterrupt ou MiniportMessageInterruptDPC d’un pilote miniport.

NDIS appelle MiniportMessageInterrupt au niveau du DIRQL de la MSI que le pilote miniport a inscrite lors d’un appel précédent à NdisMRegisterInterruptEx. Par conséquent, MiniportMessageInterrupt doit appeler le sous-ensemble des fonctions NDIS, telles que les fonctions NdisRawXxx ou NdisRead/WriteRegisterXxx , qui peuvent être appelées en toute sécurité à n’importe quel IRQL.

Exemples

Pour définir une fonction MiniportMessageInterrupt , vous devez d’abord fournir une déclaration de fonction qui identifie le type de fonction que vous définissez. Windows fournit un ensemble de types de fonctions pour les pilotes. La déclaration d’une fonction à l’aide des types de fonction permet à l’analyse du code pour les pilotes, au vérificateur de pilotes statiques (SDV) et à d’autres outils de vérification de trouver des erreurs. Il s’agit d’une exigence pour l’écriture de pilotes pour le système d’exploitation Windows.

Par exemple, pour définir une fonction MiniportMessageInterrupt nommée « MyMessageInterrupt », utilisez le type MINIPORT_MESSAGE_INTERRUPT comme indiqué dans cet exemple de code :

MINIPORT_MESSAGE_INTERRUPT MyMessageInterrupt;

Ensuite, implémentez votre fonction comme suit :

_Use_decl_annotations_
BOOLEAN
 MyMessageInterrupt(
    NDIS_HANDLE  MiniportInterruptContext,
    ULONG  MessageId,
    PBOOLEAN  QueueDefaultInterruptDpc,
    PULONG  TargetProcessors
    )
  {...}

Le type de fonction MINIPORT_MESSAGE_INTERRUPT est défini dans le fichier d’en-tête Ndis.h. Pour identifier plus précisément les erreurs lors de l’exécution des outils d’analyse du code, veillez à ajouter l’annotation Use_decl_annotations à votre définition de fonction. L’annotation Use_decl_annotations garantit que les annotations appliquées au type de fonction MINIPORT_MESSAGE_INTERRUPT dans le fichier d’en-tête sont utilisées. Pour plus d’informations sur la configuration requise pour les déclarations de fonction, consultez Déclaration de fonctions à l’aide de types de rôles de fonction pour les pilotes NDIS.

Pour plus d’informations sur Use_decl_annotations, consultez Annotating Function Behavior.

Configuration requise

Condition requise	Valeur
Client minimal pris en charge	Pris en charge dans NDIS 6.0 et versions ultérieures.
Plateforme cible	Windows
En-tête	ndis.h (inclure Ndis.h)
IRQL	Voir la section Notes