Controlador de interrupção virtual

O hipervisor virtualiza a entrega de interrupções para processadores virtuais.

Architecture-Specific Controladores de Interrupções Virtuais

Em plataformas x64

Em plataformas x64, a virtualização de interrupções é feita através do uso de um controlador sintético de interrupções (SynIC), que é uma extensão de um API local virtualizado; ou seja, cada processador virtual tem uma instância APIC local com as extensões SynIC. Estas extensões fornecem um mecanismo simples de comunicação entre partições, descrito no capítuloInter-Partition Comunicação .

Nas plataformas ARM64

Nas plataformas ARM64, o hipervisor expõe um Controlador de Interrupções Genérico (GIC) virtual ARM que cumpre a especificação da arquitetura ARM GIC. As partições convidadas devem consultar a Especificação da Arquitetura ARM GIC para detalhes sobre a interface GIC virtual, registos e mecanismos de gestão de interrupções.

Categorias de Interrupção

As interrupções entregues a uma partição dividem-se em duas categorias: externas e internas. As interrupções externas originam-se de outras partições ou dispositivos, e as interrupções internas originam-se dentro da própria partição.

Interrupções externas são geradas nas seguintes situações:

• Um dispositivo físico de hardware gera uma interrupção de hardware.
• Uma partição pai afirma uma interrupção virtual (tipicamente no processo de emulação de um dispositivo de hardware).
• O hipervisor entrega uma mensagem (por exemplo, devido a uma interceção) para uma partição.
• Outra partição publica uma mensagem.
• Outra partição sinaliza um evento.

As interrupções internas são geradas nas seguintes situações:

• Um processador virtual acede ao registo de comandos de interrupção APIC (ICR).
• Um temporizador sintético expira.

APIC local (apenas x64)

Em plataformas x64, o SynIC é um superconjunto de um API local. A interface para este APIC é dada por um conjunto de registos mapeados de memória de 32 bits. Este APIC local (incluindo o comportamento dos registos mapeados em memória) é geralmente compatível com o APIC local nos sistemas P4/Xeon, conforme descrito na documentação da Intel e AMD.

A virtualização local do APIC do hipervisor pode desviar-se da operação física do APIC nos seguintes pequenos aspetos:

• Em sistemas físicos, a IA32_APIC_BASE MSR pode ser diferente para cada processador do sistema. O hipervisor pode exigir que este MSR contenha o mesmo valor para todos os processadores virtuais dentro de uma partição. Assim, este MSR pode ser tratado como um valor de toda a partição. Se um processador virtual modificar este registo, o valor pode efetivamente propagar-se para todos os processadores virtuais dentro da partição.
• O IA32_APIC_BASE MSR define um bit de "habilitação global" para ativar ou desativar o APIC. O APIC virtualizado pode estar sempre ativado. Se sim, este bit estará sempre definido para 1.
• O APIC local do hipervisor pode não ser capaz de gerar SMIs virtuais (interrupções de gestão de sistema).
• Se múltiplos processadores virtuais dentro de uma partição receberem IDs APIC idênticos, o comportamento da entrega de interrupções alvo é limitadamente indefinido. Ou seja, o hipervisor é livre para entregar a interrupção a apenas um processador virtual, todos os processadores virtuais com o ID APIC especificado, ou sem processadores virtuais. Esta situação é considerada um erro de programação de convidados.
• Alguns dos registos APIC mapeados em memória podem ser acedidos através de MSRs virtuais.
• O hipervisor pode não permitir que um convidado modifique os seus IDs APIC.

As partes restantes desta secção descrevem apenas os aspetos da funcionalidade do SynIC que são extensões do API local.

Acessos MSR APIC Locais (apenas x64)

Em plataformas x64, o hipervisor fornece acesso acelerado MSR a registos APIC mapeados de memória de alta utilização. Estes são os registos TPR, EOI e ICR. Os registos ICR graves e ICR agudos são combinados num único MSR. Por razões de desempenho, o sistema operativo convidado deve seguir a recomendação do hipervisor para a utilização dos MSRs APIC.

Estes MSRs não estão disponíveis nas plataformas ARM64, onde as operações do controlador de interrupções são realizadas através da interface virtual GIC.

HV_X64_MSR_EOI

HV_X64_MSR_ICR

HV_X64_MSR_TPR

Este MSR destina-se a acelerar o acesso ao TPR em partições convidadas em modo de 32 bits. As partições convidadas em modo de 64 bits devem definir o TPR através do CR8.

Cluster Sintético IPI

O hipervisor suporta hiperchamadas que permitem enviar interrupções virtuais fixas para um conjunto arbitrário de processadores virtuais.

Assistência EOI (apenas x64)

Nas plataformas x64, um campo na Página Virtual Processor Assist é o campo EOI Assist. O campo EOI Assist situa-se no deslocamento 0 da página sobreposta e tem 32 bits de tamanho. O formato do campo de assistência EOI é o seguinte:

Este esclarecimento não está disponível nas plataformas ARM64, onde as operações EOI são realizadas através da interface virtual GIC.

O sistema operativo convidado executa um EOI escrevendo atomicamente zero no campo EOI Assist da página virtual de assistente do VP e verificando se o campo "Não é necessário EOI" era anteriormente zero. Se for, o sistema operativo deve escrever no HV_X64_MSR_EOI MSR, desencadeando assim uma interceção no hipervisor. Recomenda-se o seguinte código para realizar uma EOI:

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

mov ecx, HV_X64_MSR_EOI
wrmsr

NoEoiRequired:

O hipervisor define o bit "Não é necessário EOI" quando injeta uma interrupção virtual se as seguintes condições forem satisfeitas:

• A interrupção virtual é desencadeada por aresta, e
• Não há interrupções de menor prioridade pendentes

Se, numa altura posterior, for solicitada uma interrupção de menor prioridade, o hipervisor elimina o "Não é necessário EOI" de modo que um EOI subsequente cause uma interceção.

No caso de interrupções aninhadas, a interceção EOI é evitada apenas para a interrupção de maior prioridade. Isto é necessário porque não é mantida uma contagem para o número de EOIs realizados pelo SO. Portanto, apenas o primeiro EOI pode ser evitado e, como o primeiro EOI elimina o bit "Não é necessário EOI", o EOI seguinte gera uma interceção. No entanto, as interrupções aninhadas são raras, por isso isto não é um problema no caso comum.

Note que os dispositivos e/ou o APIC de I/O (físico ou sintético) não precisam de ser notificados de um EOI para uma interrupção desencadeada por arestas – o hipervisor interceta esses EOIs apenas para atualizar o estado virtual do APIC. Em alguns casos, o estado APIC virtual pode ser atualizado preguiçosamente – nesses casos, o bit "NoEoiRequired" é definido pelo hipervisor a indicar ao convidado que uma interceção EOI não é necessária. Num instante posterior, o hipervisor pode derivar o estado do APIC local dependendo do valor atual do bit "NoEoiRequired".

Ativar e desativar este esclarecimento pode ser feito a qualquer momento, independentemente da atividade de interrupção e do estado APIC naquele momento. Enquanto o esclarecimento está habilitado, as EOIs convencionais ainda podem ser realizadas independentemente do valor "Não é necessário EOI", mas não alcançarão o benefício de desempenho do esclarecimento.