Tables de description système ACPI

L’implémentation de la spécification matérielle ACPI (Advanced Configuration and Power Interface) n’est pas requise sur les plateformes soC, mais la plupart des spécifications logicielles ACPI sont (ou peuvent être) requises. ACPI définit un mécanisme générique et extensible de passage de table, ainsi que des tables spécifiques pour décrire la plateforme au système d’exploitation.

Les structures et en-têtes de table, y compris les champs ID et somme de contrôle, sont définis dans la spécification ACPI 5.0. Windows utilise ce mécanisme de transmission de table, en plus des tables spécifiques décrites dans cet article.

L’idée derrière ces tables est de permettre aux logiciels génériques de prendre en charge les blocs de propriété intellectuelle standard qui peuvent être intégrés à différentes plateformes de différentes manières. Avec la stratégie de table, les attributs de variable de plateforme d’une plateforme particulière sont fournis dans une table et utilisés par des logiciels génériques pour s’adapter à l’ensemble spécifique de blocs IP intégrés à la plateforme. Ce logiciel peut donc être écrit une fois, soigneusement testé, puis optimisé au fil du temps.

Pointeur de description du système racine (RSDP)

Windows dépend du microprogramme UEFI pour démarrer la plateforme matérielle. Par conséquent, Windows utilisera la table système EFI pour localiser le RSDP, comme décrit dans la section 5.2.5.2, « Recherche du RSDP sur les systèmes compatibles UEFI », de la spécification ACPI 5.0. Le microprogramme de la plateforme indique l’adresse du RSDT ou du XSDT dans le RSDP. (Si les deux adresses de table sont fournies, Windows préfère le XSDT.)

Table de description du système racine (RSDT)

Le RSDT (ou XSDT) inclut des pointeurs vers d’autres tables de description système fournies sur la plateforme. Plus précisément, ce tableau contient des pointeurs vers les tableaux suivants :

• Table matérielle ACPI fixe (FADT)

• Table de contrôleur d’interruption multiple (MADT)

• Optionnellement, la table de ressources système principale (CSRT)

• Tableau de ports de débogage 2 (DBG2)

• Table des ressources graphiques de démarrage (BGRT)

• Table de données de performances du microprogramme (FPDT)

• Table de description du système de base (DSDT)

• Éventuellement, tables de description système supplémentaires (SSDT)

Table de description ACPI fixe (FADT)

La table de matériel ACPI fixe (FADT) contient des informations importantes sur les différentes fonctionnalités matérielles fixes disponibles sur la plateforme. Pour prendre en charge les plateformes ACPI réduites en matériel, ACPI 5.0 étend la définition de table FADT comme suit :

• Le champ Indicateurs dans le FADT (offset 112) a deux nouveaux indicateurs :

  HARDWARE_REDUCED_ACPI décalage de bits 20. Indique que le matériel ACPI n’est pas disponible sur cette plateforme. Cet indicateur doit être défini si le modèle de programmation matérielle fixe ACPI n’est pas implémenté.

  LOW_POWER_S0_IDLE_CAPABLE décalage de bit 21. Indique que la plateforme prend en charge les états inactifs à faible alimentation au sein de l’état d’alimentation du système ACPI S0 qui sont plus économes en énergie que n’importe quel état de veille Sx. Si cet indicateur est défini, Windows n’essaie pas de dormir et de reprendre, mais utilise plutôt les états inactifs de la plateforme et la veille connectée.

• Le champ PREFERRED_PM_PROFILE FADT (offset d’octet 45) a une nouvelle entrée de rôle, « Tablette ». Ce rôle influence la stratégie de gestion de l’alimentation pour l’affichage et l’entrée, et affecte l’affichage des claviers visuels.

• Le champ « indicateurs d'architecture de démarrageIA-PC » (décalage 109) inclut un nouvel indicateur « CMOS RTC Non présent » (décalage de bits 5) pour indiquer que le RTC CMOS du PC n'est pas implémenté ou n'existe pas aux adresses héritées. Si cet indicateur est défini, la plateforme doit implémenter l’appareil ACPI Time and Alarm Control Method. Pour plus d’informations, consultez la section Temps et alarme des méthodes de contrôle dans l’article sur les appareils définis par ACPI .

• De nouveaux champs sont ajoutés pour prendre en charge la mise en veille/reprise du PC traditionnel sur les plateformes ACPI réduites par matériel. Ces champs sont ignorés par Windows, mais doivent être présents dans la table pour la conformité.

• Si l’indicateur HARDWARE_REDUCED_ACPI est défini, tous les champs relatifs à la spécification matérielle ACPI sont ignorés par le système d’exploitation.

Tous les autres paramètres FADT conservent leurs significations de la version précédente, ACPI 4.0. Pour plus d’informations, consultez la section 5.2.9, « Table de description ACPI fixe (FADT) » de la spécification ACPI 5.0.

Table de Description Multiple de l'APIC (Multiple APIC Description Table)

Dans les implémentations PC d’ACPI, la table de description APIC multiple (MADT) et les descripteurs de contrôleur d’interruption spécifiques aux PC sont utilisés pour décrire le modèle d’interruption du système. Pour les plateformes SoC basées sur Arm, ACPI 5.0 ajoute des descripteurs pour le contrôleur d’interruption générique d’Arm Holdings (GIC) et le serveur de distribution GIC. Windows inclut la prise en charge de la boîte de réception pour le serveur de distribution GIC et GIC. Pour plus d’informations sur ces descripteurs, consultez les sections 5.2.12.14, « Structure GIC » et 5.2.12.15, « GIC Distributor Structure », de la spécification ACPI 5.0.

Les structures de descripteur du contrôleur d’interruption sont répertoriées immédiatement après le champ Indicateurs dans le MADT. Pour les plateformes Arm, un descripteur est répertorié pour chaque GIC, suivi d’un pour chaque serveur de distribution GIC. Le GIC correspondant au processeur de démarrage doit être la première entrée dans la liste des descripteurs du contrôleur d’interruption.

Table de description générique de temporisateur (GTDT)

Comme avec le contrôleur d’interruption, il existe une table de description du minuteur standard dans ACPI. Pour les systèmes Arm qui utilisent le minuteur GIT, le GTDT d’ACPI peut être utilisé pour tirer parti de la prise en charge intégrée de GIT dans Windows.

Table de ressources système principales (CSRT)

Les ressources système principales (CSR) sont des fonctions matérielles partagées telles que les contrôleurs d’interruption, les minuteurs et les contrôleurs DMA auxquels le système d’exploitation doit sérialiser l’accès. Là où existent les normes du secteur pour les fonctionnalités telles que les minuteurs et les contrôleurs d’interruption (sur les architectures x86 et Arm), Windows prend en charge ces fonctionnalités en fonction des tables standard décrites dans ACPI (par exemple, MADT et GTDT). Toutefois, jusqu’à ce que le secteur converge sur les normes d’interface du contrôleur DMA, il est nécessaire de prendre en charge certains appareils non standard dans le système d’exploitation.

Windows prend en charge le concept d’extensions HAL pour résoudre ce problème. Les extensions HAL sont des modules spécifiques à SoC, implémentés en tant que DLL, qui adaptent Windows HAL à une interface matérielle spécifique d’une classe spécifique de CSR requise par Windows. Pour identifier et charger ces modules CSR non standard, Microsoft a défini une nouvelle table ACPI. Ce tableau, qui a une signature réservée de « CSRT » dans la spécification ACPI, doit être inclus dans le RSDT si des CSR non standard sont utilisés sur la plateforme.

Le CSRT décrit les groupes de ressources de CSR, où chaque groupe de ressources identifie le matériel d’un type particulier. Windows utilise l’identificateur fourni pour le groupe de ressources pour rechercher et charger l’extension HAL requise pour ce groupe. Les groupes de ressources au sein du CSRT peuvent également contenir des descripteurs de ressources individuels, en fonction du type CSR et des besoins de l’extension HAL. Le format et l’utilisation de ces descripteurs de ressources sont définis par l’enregistreur d’extension HAL, qui peut rendre l’extension beaucoup plus portable et ainsi prendre en charge différentes plateformes SoC simplement en modifiant les descripteurs de ressources contenus dans le CSRT.

Pour prendre en charge la maintenance des extensions HAL et pour gérer les ressources système utilisées par ces extensions, chaque groupe de ressources décrit dans le CSRT doit également être représenté en tant qu’appareil dans l’espace de noms ACPI de la plateforme. Pour plus d’informations, consultez la section « Table de description système différenciée (DSDT) » suivante. Les identificateurs d’appareil utilisés dans l’en-tête du groupe de ressources doivent correspondre aux identificateurs utilisés dans le nœud d’espace de noms de l’appareil. Pour plus d'informations, consultez la section Identification de l'appareil dans l'ACPI de l'article Objets de l'espace de noms de gestion des appareils. L’existence de ces dispositifs de l'espace de noms du groupe de ressources permet à l’extension HAL d’être gérée par le service Windows Update.

Pour plus d’informations, consultez la spécification CSRT (Core System Resources Table).

Port de débogage Tableau 2 (DBG2)

Microsoft nécessite un port de débogage sur tous les systèmes. Pour décrire le ou les ports de débogage intégrés à une plateforme, Microsoft définit le tableau de ports de débogage 2 (DBG2) pour ACPI. Ce tableau spécifie un ou plusieurs ports indépendants à des fins de débogage. La présence de la table DBG2 indique que la plateforme inclut au moins un port de débogage. Ce tableau inclut des informations sur l’identité et la configuration du ou des ports de débogage. La table se trouve dans la mémoire système avec d’autres tables ACPI et doit être référencée dans la table ACPI RSDT.

Windows utilise la valeur de type de port dans la table DBG2 pour identifier et charger le transport du débogueur de noyau (par exemple, USB ou série) requis par le système. Le transport KD utilise ensuite la valeur de sous-type de port dans la table DBG2 pour identifier l’interface matérielle utilisée par le port. D’autres informations de la table DBG2 spécifient l’adresse système des registres de port, qui est utilisé par le module d’interface matérielle pour le sous-type spécifié. Enfin, la table DBG2 doit inclure une référence au nœud de périphérique dans l’espace de noms ACPI qui correspond au port de débogage. Cette référence permet à Windows de gérer les conflits entre l’utilisation du débogage et l’utilisation normale de l’appareil, le cas échéant, et également d’intégrer le débogueur à des transitions d’alimentation.

Pour plus d’informations, consultez la spécification Microsoft Debug Port Table 2 (DBG2).

Table de description système différenciée (DSDT)

Dans ACPI, les périphériques et les fonctionnalités matérielles système de la plateforme sont décrits dans la table de description système différenciée (DSDT), qui est chargée au démarrage ou dans les tables de description du système secondaire (SSDT), qui sont chargées au démarrage ou chargées dynamiquement au moment de l’exécution. Pour les SoCs, la configuration de la plateforme est généralement statique, donc le DSDT peut être suffisant, bien que les SSDT puissent également être utilisés pour améliorer la modularité de la description de la plateforme.

ACPI définit un langage interprété (langage source ACPI ou ASL) et un environnement d’exécution (machine virtuelle ACPI) pour décrire les appareils et fonctionnalités système, ainsi que leurs contrôles spécifiques à la plateforme, de manière indépendante du système d’exploitation. ASL est utilisé pour définir des objets nommés dans l’espace de noms ACPI, et le compilateur Microsoft ASL est utilisé pour produire le code d’octet AML (ACPI Machine Language) pour la transmission au système d’exploitation dans le DSDT. Le pilote ACPI Windows, Acpi.sys, implémente la machine virtuelle ACPI et interprète le code d’octet AML. Un objet AML peut simplement renvoyer des informations de description. Ou bien, un objet AML peut être une méthode qui effectue des opérations d’E/S ou de calcul. Une méthode de contrôle est un objet AML exécutable qui utilise les pilotes de périphérique du système d’exploitation pour effectuer des opérations d’E/S sur le matériel de la plateforme. ASL utilise OpRegions pour extraire les différents espaces d’adressage accessibles dans le système d’exploitation. Les méthodes de contrôle effectuent des opérations d’E/S sous la forme d’une série de transferts vers et depuis des champs nommés déclarés dans OpRegions.

Pour plus d’informations sur OpRegions, consultez la section 5.5.2.4, « Accès aux régions d’opération », dans la spécification ACPI 5.0. Pour plus d’informations sur les méthodes ASL et de contrôle, consultez la section 5.5, « Espace de noms ACPI », dans la spécification ACPI 5.0.

Windows prend en charge le développement et le débogage du code ASL. Le compilateur ASL inclut un désassembleur pour permettre à l’implémenteur de charger un espace de noms à partir d’une cible de débogage. Le compilateur ASL peut ensuite être utilisé pour réappliquer l’espace de noms à la cible pour le prototypage et le test rapides, sans avoir à flasher le microprogramme système. En outre, le débogueur du noyau Windows, conjointement avec une version vérifiée (CHK) du pilote Acpi.sys, prend en charge le suivi et l’analyse de l’exécution AML. Pour plus d’informations, consultez le débogueur AMLI.

Table des atténuations de sécurité Windows SMM (WSMT)

La spécification WSMT (Windows SMM Security Mitigations Table) contient des détails sur une table ACPI (Advanced Configuration and Power Interface) créée pour une utilisation avec les systèmes d’exploitation Windows qui prennent en charge les fonctionnalités de sécurité basée sur la virtualisation (VBS) Windows.

Ces informations s’appliquent aux systèmes d’exploitation suivants :

Windows Server 2016

Windows 10, version 1607

Pour plus d’informations, consultez la spécification WSMT (Windows SMM Security Mitigations Table) (téléchargement DOCX).

Table de microprogramme de démarrage iSCSI (iBFT)

La table iSCSI Boot Firmware (iBF) (iBFT) est un bloc d’informations qui contient différents paramètres utiles au processus de démarrage iSCSI. L’iBFT est le mécanisme par lequel les valeurs des paramètres iBF sont transmises au système d’exploitation. L'iBF construit et remplit l'iBFT. L’iBFT est disponible pour le système d’exploitation Windows afin d’activer un flux cohérent du processus de démarrage.

Pour plus d’informations, consultez la spécification iSCSI Boot Firmware Table (iBFT) (téléchargement DOCX).