Controlador de interrupción virtual

El hipervisor virtualiza la entrega de interrupciones a los procesadores virtuales.

Architecture-Specific controladores de interrupción virtual

En plataformas x64

En las plataformas x64, la virtualización de interrupciones se realiza mediante el uso de un controlador de interrupción sintético (SynIC), que es una extensión de un APIC local virtualizado; es decir, cada procesador virtual tiene una instancia de APIC local con las extensiones de SynIC. Estas extensiones proporcionan un mecanismo de comunicación entre particiones simple que se describe en el capítulo comunicación deInter-Partition .

En plataformas ARM64

En las plataformas ARM64, el hipervisor expone un controlador de interrupción genérico (GIC) de ARM virtual que se ajusta a la especificación de arquitectura arm GIC. Las particiones invitadas deben consultar la especificación de arquitectura de ARM GIC para obtener más información sobre la interfaz virtual de GIC, los registros y los mecanismos de control de interrupciones.

Categorías de interrupción

Las interrupciones entregadas a una partición se dividen en dos categorías: externas e internas. Las interrupciones externas se originan en otras particiones o dispositivos, y las interrupciones internas se originan en la propia partición.

Las interrupciones externas se generan en las situaciones siguientes:

• Un dispositivo de hardware físico genera una interrupción de hardware.
• Una partición primaria afirma una interrupción virtual (normalmente en el proceso de emulación de un dispositivo de hardware).
• El hipervisor entrega un mensaje (por ejemplo, debido a una interceptación) a una partición.
• Otra partición publica un mensaje.
• Otra partición señala un evento.

Las interrupciones internas se generan en las situaciones siguientes:

• Un procesador virtual accede al registro de comandos de interrupción de APIC (ICR).
• Expira un temporizador sintético.

APIC local (solo x64)

En plataformas x64, SynIC es un superconjunto de un APIC local. La interfaz de este APIC se da mediante un conjunto de registros asignados a memoria de 32 bits. Este APIC local (incluido el comportamiento de los registros asignados a memoria) suele ser compatible con el APIC local en sistemas P4/Xeon, tal como se describe en la documentación de Intel y AMD.

La virtualización APIC local del hipervisor puede desviarse de la operación física de APIC de las siguientes maneras secundarias:

• En los sistemas físicos, el IA32_APIC_BASE MSR puede ser diferente para cada procesador del sistema. El hipervisor puede requerir que este MSR contenga el mismo valor para todos los procesadores virtuales dentro de una partición. Por lo tanto, este MSR puede tratarse como un valor de toda la partición. Si un procesador virtual modifica este registro, el valor puede propagarse eficazmente a todos los procesadores virtuales de la partición.
• El IA32_APIC_BASE MSR define un bit "global enable" para habilitar o deshabilitar APIC. El APIC virtualizado siempre se puede habilitar. Si es así, este bit siempre se establecerá en 1.
• Es posible que el APIC local del hipervisor no pueda generar SME virtuales (interrupciones de administración del sistema).
• Si se asignan varios procesadores virtuales dentro de una partición identificadores APIC idénticos, el comportamiento de la entrega de interrupciones de destino no está definido de forma limitada. Es decir, el hipervisor es libre de entregar la interrupción a un solo procesador virtual, a todos los procesadores virtuales con el identificador de APIC especificado o a ningún procesador virtual. Esta situación se considera un error de programación de invitado.
• Se puede acceder a algunos de los registros de APIC asignados a memoria mediante MSR virtuales.
• Es posible que el hipervisor no permita que un invitado modifique sus identificadores APIC.

Las partes restantes de esta sección describen solo los aspectos de la funcionalidad de SynIC que son extensiones del APIC local.

Accesos APIC MSR locales (solo x64)

En las plataformas x64, el hipervisor proporciona acceso acelerado de MSR a registros APIC asignados a memoria de uso elevado. Estos son los registros de TPR, EOI y ICR. Los registros altos de ICR e ICR se combinan en un MSR. Por motivos de rendimiento, el sistema operativo invitado debe seguir la recomendación del hipervisor para el uso de las MSR de APIC.

Estas MSR no están disponibles en plataformas ARM64, donde las operaciones del controlador de interrupción se realizan a través de la interfaz GIC virtual.

HV_X64_MSR_EOI

HV_X64_MSR_ICR

HV_X64_MSR_TPR

Este MSR está diseñado para acelerar el acceso al TPR en particiones invitadas en modo de 32 bits. Las particiones de invitado en modo de 64 bits deben establecer el TPR mediante CR8.

IPI de clúster sintético

El hipervisor admite hiperllamadas que permiten enviar interrupciones fijas virtuales a un conjunto arbitrario de procesadores virtuales.

Asistencia EOI (solo x64)

En las plataformas x64, un campo de la página Virtual Processor Assist es el campo EOI Assist. El campo EOI Assist reside en el desplazamiento 0 de la página de superposición y tiene un tamaño de 32 bits. El formato del campo de asistencia EOI es el siguiente:

Esta iluminación no está disponible en plataformas ARM64, donde las operaciones de EOI se realizan a través de la interfaz GIC virtual.

El sistema operativo invitado realiza una EOI escribiendo de forma atómica cero en el campo EOI Assist de la página de asistencia virtual VP y comprobando si el campo "No EOI requerido" era cero anteriormente. Si es así, el sistema operativo debe escribir en el HV_X64_MSR_EOI MSR, lo que desencadena una interceptación en el hipervisor. Se recomienda el código siguiente para realizar una EOI:

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

mov ecx, HV_X64_MSR_EOI
wrmsr

NoEoiRequired:

El hipervisor establece el bit "No EOI required" cuando inserta una interrupción virtual si se cumplen las condiciones siguientes:

• La interrupción virtual se desencadena de forma perimetral y
• No hay interrupciones de prioridad inferior pendientes

Si, en un momento posterior, se solicita una interrupción de prioridad inferior, el hipervisor borra el "No EOI requerido" de modo que una EOI posterior provoque una interceptación.

En el caso de interrupciones anidadas, la interceptación de EOI solo se evita para la interrupción de prioridad más alta. Esto es necesario, ya que no se mantiene ningún recuento para el número de EOIs realizados por el sistema operativo. Por lo tanto, solo se puede evitar el primer EOI y, dado que el primer EOI borra el bit "No EOI Required", el siguiente EOI genera una interceptación. Sin embargo, las interrupciones anidadas son poco frecuentes, por lo que esto no es un problema en el caso común.

Tenga en cuenta que los dispositivos o el APIC de E/S (físico o sintético) no deben recibir una notificación de un EOI para una interrupción desencadenada por el borde: el hipervisor intercepta dichos EOIs solo para actualizar el estado de APIC virtual. En algunos casos, el hipervisor establece el estado de APIC virtual que indica al invitado que no es necesaria una interceptación de EOI. En un instante posterior, el hipervisor puede derivar el estado del APIC local en función del valor actual del bit "NoEoiRequired".

La habilitación y deshabilitación de esta iluminación se puede realizar en cualquier momento independientemente de la actividad de interrupción y el estado de APIC en ese momento. Aunque la iluminación está habilitada, las EOIs convencionales todavía se pueden realizar independientemente del valor "No EOI requerido", pero no se darán cuenta de la ventaja de rendimiento de la iluminación.