MINIPORT_MESSAGE_INTERRUPT fonction de rappel (ndis.h)

Article
02/07/2025

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

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

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 vers 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é par un message (MSI). MessageId est un index à un IO_INTERRUPT_MESSAGE_INFO_ENTRY structure à l’intérieur d’une structure IO_INTERRUPT_MESSAGE_INFO. NDIS transmet un pointeur à la structure de IO_INTERRUPT_MESSAGE_INFO associée au membre MessageInfoTable lorsque le pilote s’inscrit correctement à MSI auprès de la fonction NdisMRegisterInterruptEx.

[out] QueueDefaultInterruptDpc

Pointeur vers une variable booléenne définie par le pilote miniport avant de retourner à partir de cet appel. Un pilote miniport définit cette valeur sur TRUE pour indiquer que le pilote requiert une DPC sur le processeur par défaut (actuel). 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 des contrôleurs de domaine.

[out] TargetProcessors

Masque de bits qui indique les processeurs cibles pour lesquels NDIS doit planifier une 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 une DPC pour l’UC 0. Si l’appelant définit le bit 1, NDIS planifie une DPC pour le processeur 1, et ainsi de suite.

Remarque NDIS 6.20 et versions ultérieures ne doivent pas utiliser ce paramètre pour planifier les 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 des contrôleurs de domaine.

Valeur de retour

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 pour la prise en charge des interruptions signalées par message (MSI) avec la fonction NdisMRegisterInterruptEx doivent fournir une fonction MiniportMessageInterrupt.

Un pilote miniport doit effectuer le plus peu 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 interface 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 à l’adresse fonction MiniportMessageInterruptDPC.

Si le pilote miniport demande des appels de procédure différée (DPCs) 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 DPCs 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 le faire, par exemple, si :

La carte réseau a généré l’interruption pour signaler l’achèvement d’une opération d’envoi ou 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 contrôleurs de domaine distincts.
L’interruption indique les paquets reçus et le pilote miniport peut traiter les paquets reçus dans des DPCs distincts, mais ' de réception côté mise à l’échelle (RSS) n’est pas activé pour le pilote miniport. Pour plus d’informations, consultez 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 contrôleurs de domaine distincts, le pilote miniport définit le paramètre QueueDefaultInterruptDpc sur FALSE. Le pilote miniport doit définir la TargetProcessors bit pour l’UC associée à chaque file d’attente de réception nonempty. NDIS planifie une DPC sur chacun des processeurs indiqués dans le groupe de processeurs 0.

Si MiniportMessageInterrupt partage des ressources pour un message spécifié, tel que des registres de carte réseau ou des variables d’état, avec une autre fonction MiniportXxx qui s’exécute à un irQL inférieur, que miniportXxx fonction doit appeler la fonction fonction NdisMSynchronizeWithInterruptEx. 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 de sa fonction MiniportInitializeEx ou MiniportHaltEx pour libérer les ressources qu’elle a allouées avec NdisMRegisterInterruptEx. Une fois NdisMDeregisterInterruptEx retourné, NDIS n’appelle pas la fonction MiniportMessageInterrupt ou MiniportMessageInterruptDPC.

NDIS appelle MiniportMessageInterrupt au niveau de la DIRQL de la MSI que le pilote miniport inscrit dans 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/WriteRegisterfonctions xxx, qui sont sécurisées pour appeler à n’importe quel irQL.

exemples de

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 fonctions permet d'Analyse du code pour les pilotes, de vérificateur de pilotes statiques (SDV) et d’autres outils de vérification recherchent des erreurs, et il est nécessaire d’écrire des 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 lorsque vous exécutez les 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 annoter le comportement de la fonction.

Exigences

Exigence	Valeur
client minimum pris en charge	Prise en charge dans NDIS 6.0 et versions ultérieures.
plateforme cible	Windows
d’en-tête	ndis.h (include Ndis.h)
IRQL	Voir la section Remarques