Contrôleur d’interruption virtuelle

L’hyperviseur virtualise l’interruption de remise aux processeurs virtuels.

Architecture-Specific contrôleurs d’interruption virtuelle

Sur les plateformes x64

Sur les plateformes x64, la virtualisation des interruptions est effectuée via l’utilisation d’un contrôleur d’interruption synthétique (SynIC) qui est une extension d’un APIC local virtualisé ; autrement dit, chaque processeur virtuel a une instance APIC locale avec les extensions SynIC. Ces extensions fournissent un mécanisme de communication inter-partition simple qui est décrit dans le chapitre Inter-Partition Communication .

Sur les plateformes ARM64

Sur les plateformes ARM64, l’hyperviseur expose un contrôleur d’interruption générique ARM virtuel (GIC) conforme à la spécification de l’architecture ARM GIC. Les partitions invitées doivent faire référence à la spécification de l’architecture ARM GIC pour plus d’informations sur l’interface, les registres et les mécanismes de gestion des interruptions virtuels.

Catégories d’interruptions

Les interruptions remises à une partition se répartissent en deux catégories : externes et internes. Les interruptions externes proviennent d’autres partitions ou périphériques, et les interruptions internes proviennent de la partition elle-même.

Les interruptions externes sont générées dans les situations suivantes :

• Un périphérique matériel physique génère une interruption matérielle.
• Une partition parente affirme une interruption virtuelle (généralement dans le processus de simulation d’un appareil matériel).
• L’hyperviseur remet un message (par exemple, en raison d’un intercept) à une partition.
• Une autre partition publie un message.
• Une autre partition signale un événement.

Les interruptions internes sont générées dans les situations suivantes :

• Un processeur virtuel accède au registre de commandes d’interruption APIC (ICR).
• Un minuteur synthétique expire.

APIC local (x64 uniquement)

Sur les plateformes x64, SynIC est un super-ensemble d’un APIC local. L’interface de cet APIC est donnée par un ensemble de registres mappés en mémoire 32 bits. Cet APIC local (y compris le comportement des registres mappés en mémoire) est généralement compatible avec les systèmes APIC locaux sur P4/Xeon, comme décrit dans la documentation d’Intel et AMD.

La virtualisation APIC locale de l’hyperviseur peut s’écarter de l’opération APIC physique de manière mineure suivante :

• Sur les systèmes physiques, la IA32_APIC_BASE MSR peut être différente pour chaque processeur du système. L’hyperviseur peut exiger que ce MSR contienne la même valeur pour tous les processeurs virtuels au sein d’une partition. Par conséquent, ce MSR peut être traité comme une valeur à l’échelle de la partition. Si un processeur virtuel modifie ce registre, la valeur peut se propager efficacement à tous les processeurs virtuels au sein de la partition.
• La IA32_APIC_BASE MSR définit un bit d'« activation globale » pour l’activation ou la désactivation de l’APIC. L’APIC virtualisé peut toujours être activé. Si c’est le cas, ce bit est toujours défini sur 1.
• L’APIC local de l’hyperviseur peut ne pas être en mesure de générer des API virtuelles (interruptions de gestion du système).
• Si plusieurs processeurs virtuels au sein d’une partition sont affectés à des ID APIC identiques, le comportement de la remise d’interruption ciblée n’est pas défini de manière limitée. Autrement dit, l’hyperviseur est libre de remettre l’interruption à un seul processeur virtuel, tous les processeurs virtuels avec l’ID APIC spécifié ou aucun processeur virtuel. Cette situation est considérée comme une erreur de programmation invité.
• Certains registres APIC mappés en mémoire sont accessibles par le biais de MSR virtuels.
• L’hyperviseur peut ne pas autoriser un invité à modifier ses ID APIC.

Les parties restantes de cette section décrivent uniquement les aspects de la fonctionnalité SynIC qui sont des extensions de l’APIC local.

Accès APIC MSR local (x64 uniquement)

Sur les plateformes x64, l’hyperviseur fournit un accès MSR accéléré aux registres APIC mappés à haute utilisation. Il s’agit des registres TPR, EOI et ICR. Les registres ICR bas et ICR élevés sont combinés en un SEUL MSR. Pour des raisons de performances, le système d’exploitation invité doit suivre la recommandation d’hyperviseur pour l’utilisation des MSR APIC.

Ces MSR ne sont pas disponibles sur les plateformes ARM64, où les opérations du contrôleur d’interruption sont effectuées via l’interface GIC virtuelle.

HV_X64_MSR_EOI

HV_X64_MSR_ICR

HV_X64_MSR_TPR

Ce MSR est destiné à accélérer l’accès au TPR en mode 32 bits partitions invitées. Les partitions invitées en mode 64 bits doivent définir le TPR par le biais de CR8.

IPI du cluster synthétique

L’hyperviseur prend en charge les hypercalls qui permettent d’envoyer des interruptions fixes virtuelles à un ensemble arbitraire de processeurs virtuels.

EOI Assist (x64 uniquement)

Sur les plateformes x64, un champ de la page Assistant processeur virtuel est le champ EOI Assist. Le champ EOI Assist se trouve à l’offset 0 de la page de superposition et est de taille de 32 bits. Le format du champ d’assistance EOI est le suivant :

Cette lumière n’est pas disponible sur les plateformes ARM64, où les opérations EOI sont effectuées via l’interface GIC virtuelle.

Le système d’exploitation invité effectue un EOI en écrivant atomiquement zéro dans le champ EOI Assist de la page d’assistance vp virtuel et en vérifiant si le champ « Aucun EOI requis » n’était précédemment égal à zéro. Si c’était le cas, le système d’exploitation doit écrire dans la HV_X64_MSR_EOI MSR, ce qui déclenche une interception dans l’hyperviseur. Le code suivant est recommandé pour effectuer un EOI :

lea rcx, [VirtualApicAssistVa]
btr [rcx], 0
jc NoEoiRequired

mov ecx, HV_X64_MSR_EOI
wrmsr

NoEoiRequired:

L’hyperviseur définit le bit « No EOI required » lorsqu’il injecte une interruption virtuelle si les conditions suivantes sont satisfaites :

• L’interruption virtuelle est déclenchée par la périphérie et
• Il n’y a pas d’interruptions de priorité inférieure en attente

Si, ultérieurement, une interruption de priorité inférieure est demandée, l’hyperviseur efface le message « Aucun EOI requis » afin qu’un EOI ultérieur provoque une interception.

En cas d’interruptions imbriquées, l’interception EOI n’est évitée que pour l’interruption de priorité la plus élevée. Cela est nécessaire, car aucun nombre n’est conservé pour le nombre d’EOIs effectués par le système d’exploitation. Par conséquent, seul le premier EOI peut être évité et, étant donné que le premier EOI efface le bit « No EOI Required », l’EOI suivant génère une interception. Toutefois, les interruptions imbriquées sont rares, ce n’est donc pas un problème dans le cas courant.

Notez que les appareils et/ou les E/S APIC (physiques ou synthétiques) ne doivent pas être avertis d’une EOI pour une interruption déclenchée par la périphérie : l’hyperviseur intercepte ces EOIs uniquement pour mettre à jour l’état APIC virtuel. Dans certains cas, l’état APIC virtuel peut être mis à jour de manière différée , dans ce cas, le bit « NoEoiRequired » est défini par l’hyperviseur indiquant à l’invité qu’une interception EOI n’est pas nécessaire. À un instant ultérieur, l’hyperviseur peut dériver l’état de l’APIC local en fonction de la valeur actuelle du bit « NoEoiRequired ».

L’activation et la désactivation de cet éclairage peuvent être effectuées à tout moment indépendamment de l’activité d’interruption et de l’état APIC à ce moment-là. Bien que l’éclairage soit activé, les EOO conventionnelles peuvent toujours être effectuées indépendamment de la valeur « Aucune EOI requise », mais elles ne réaliseront pas l’avantage des performances de l’éclairage.