Virtualização aninhada

A virtualização aninhada refere-se ao hipervisor Hyper-V emulando extensões de virtualização de hardware. Essas extensões emuladas podem ser usadas por outros softwares de virtualização (por exemplo, um hipervisor aninhado) para serem executadas na plataforma Hyper-V.

Essa funcionalidade só está disponível para partições de convidado. Ele deve ser habilitado por máquina virtual. Não há suporte para virtualização aninhada em uma partição raiz do Windows.

A terminologia a seguir é usada para definir vários níveis de virtualização aninhada:

Em comparação com bare-metal, os hipervisores podem incorrer em uma regressão significativa de desempenho ao serem executados em uma VM. Os hipervisores L1 podem ser otimizados para serem executados em uma VM Hyper-V usando interfaces esclarecidas fornecidas pelo hipervisor L0.

Atualmente, essa funcionalidade só tem suporte no x64.

VMCS habilitado (Intel)

Em plataformas Intel, o software de virtualização usa VMCSs (estruturas de dados de controle de máquina virtual) para configurar o comportamento do processador relacionado à virtualização. Os VMCSs devem se tornar ativos usando uma instrução VMPTRLD e modificados usando instruções VMREAD e VMWRITE. Essas instruções geralmente são um gargalo significativo para virtualização aninhada porque devem ser emuladas.

O hipervisor expõe um recurso "VMCS habilitado" que pode ser usado para controlar o comportamento do processador relacionado à virtualização usando uma estrutura de dados na memória física convidada. Essa estrutura de dados pode ser modificada usando instruções normais de acesso à memória, portanto, não há necessidade de o hipervisor L1 executar instruções VMREAD ou VMWRITE ou VMPTRLD.

O hipervisor L1 pode optar por usar VMCSs habilitados gravando 1 no campo correspondente na Página de Assistência ao Processador Virtual. Outro campo na página de assistência de VP controla o VMCS habilitado atualmente ativo. Cada VMCS habilitado tem exatamente uma página (4 KB) de tamanho e deve ser zero inicialmente. Nenhuma instrução VMPTRLD deve ser executada para tornar um VMCS habilitado ativo ou atual.

Depois que o hipervisor L1 executa uma entrada de VM com um VMCS habilitado, o VMCS é considerado ativo no processador. Um VMCS habilitado só pode estar ativo em um único processador ao mesmo tempo. O hipervisor L1 pode executar uma instrução VMCLEAR para fazer a transição de um VMCS habilitado do estado ativo para o não ativo. Qualquer instrução VMREAD ou VMWRITE enquanto um VMCS habilitado está ativo não tem suporte e pode resultar em um comportamento inesperado.

A estrutura HV_VMX_ENLIGHTENED_VMCS define o layout do VMCS habilitado. Todos os campos não sintéticos são mapeados para uma codificação VMCS física da Intel.

Limpar Campos

O hipervisor L0 pode optar por armazenar em cache partes do VMCS habilitado. Os campos limpos do VMCS habilitados controlam quais partes do VMCS habilitado são recarregadas da memória de convidado em uma entrada de VM aninhada. O hipervisor L1 deve limpar os campos limpos do VMCS correspondentes sempre que modifica o VMCS habilitado, caso contrário, o hipervisor L0 pode usar uma versão obsoleta.

A iluminação de campos limpos é controlada por meio do campo sintético "CleanFields" do VMCS esclarecido. Por padrão, todos os bits são definidos de modo que o hipervisor L0 deve recarregar os campos VMCS correspondentes para cada entrada de VM aninhada.

Descoberta de Recursos

O suporte para uma interface VMCS esclarecida é relatado com 0x40000004 folha CPUID.

A estrutura do VMCS esclarecida é usada para levar em conta as alterações futuras. Cada estrutura do VMCS habilitada contém um campo de versão, que é relatado pelo hipervisor L0.

A única versão do VMCS com suporte atualmente é 1.

Considerações sobre a implementação do hipervisor

Para a maioria dos campos VMCS, o campo VMCS habilitado correspondente terá suporte para uma VM se o campo VMCS tiver suporte para a VM, conforme determinado por meio de mecanismos de descoberta de recursos arquitetônicos. As exceções são relatadas no 0x4000000A folha CPUID.

Nos casos em que os mecanismos de descoberta de recursos de arquitetura indicam suporte para um campo VMCS para o qual nenhum campo VMCS habilitado é definido, o hipervisor L1 não deve habilitar o recurso se optar por usar VMCS habilitado.

O hipervisor Hyper-V L0 não indicará suporte para um campo VMCS para o qual nenhum campo ou exceção do VMCS habilitado é definido. Se outro hipervisor L0 precisar de um novo campo ou exceção do VMCS habilitado para ser definido, entre em contato com a Microsoft.

Campos VMCB inlighened (AMD)

A AMD tem espaço reservado no VMCB para uso de hipervisor, bem como um bit limpo associado. Os bytes reservados estão na seção de controle, deslocamento 0x3E0-3FF, do VMCB. O bit limpo é o bit 31 (o bit limpo deve ser invalidado sempre que o hipervisor modifica a área "iluminações" do VMCB).

Hyper-V utiliza a área reservada do VMCB para configurar os esclarecimentos. A estrutura HV_SVM_ENLIGHTENED_VMCB_FIELDS documenta o formato.

Bitmap do MSR habilitado

O hipervisor L0 emula os controles "MSR-Bitmap" em plataformas Intel e AMD que permitem que o software de virtualização controle quais acessos MSR geram interceptações.

O hipervisor L1 pode colaborar com o hipervisor L0 para tornar os acessos MSR mais eficientes. Ele pode habilitar bitmaps DE MSR habilitados definindo o campo correspondente nos campos VMCS/VMCB habilitados como 1. Quando habilitado, o hipervisor L0 não monitora os bitmaps msr para alterações. Em vez disso, o hipervisor L1 deve invalidar o campo limpo correspondente depois de fazer alterações em um dos bitmaps msr.

O suporte para o bitmap do MSR esclarecido é relatado no 0x4000000A folha CPUID.

Compatibilidade com migração dinâmica

Hyper-V tem a capacidade de migrar ao vivo uma partição filho de um host para outro host. As migrações ao vivo normalmente são transparentes para a partição filho. No entanto, no caso de virtualização aninhada, o hipervisor L1 pode precisar estar ciente das migrações.

Notificação de migração ao vivo

Um hipervisor L1 pode solicitar para ser notificado quando sua partição é migrada. Essa funcionalidade é enumerada em CPUID como privilégio "AccessReenlightenmentControls". O hipervisor L0 expõe um MSR sintético (HV_X64_MSR_REENLIGHTENMENT_CONTROL) que pode ser usado pelo hipervisor L1 para configurar um vetor de interrupção e um processador de destino. O hipervisor L0 injetará uma interrupção com o vetor especificado após cada migração.

#define HV_X64_MSR_REENLIGHTENMENT_CONTROL (0x40000106)

typedef union
{
    UINT64 AsUINT64;
    struct
    {
        UINT64 Vector :8;
        UINT64 RsvdZ1 :8;
        UINT64 Enabled :1;
        UINT64 RsvdZ2 :15;
        UINT64 TargetVp :32;
    };
} HV_REENLIGHTENMENT_CONTROL;

O vetor especificado deve corresponder a uma interrupção APIC fixa. TargetVp especifica o índice do processador virtual.

Emulação do TSC

Uma partição de convidado pode ser migrada ao vivo entre dois computadores com frequências TSC diferentes. Nesses casos, o valor TscScale da página TSC de referência pode precisar ser recomputado.

Opcionalmente, o hipervisor L0 emula todos os acessos TSC após uma migração até que o hipervisor L1 tenha tido a oportunidade de recompute o valor de TscScale. O hipervisor L1 pode optar pela emulação do TSC gravando no MSR HV_X64_MSR_TSC_EMULATION_CONTROL. Se aceito, o hipervisor L0 emula acessos TSC após a migração.

O hipervisor L1 pode consultar se os acessos TSC estão sendo emulados no momento usando o HV_X64_MSR_TSC_EMULATION_STATUS MSR. Por exemplo, o hipervisor L1 pode assinar notificações de Migração Dinâmica e consultar o status do TSC depois de receber a interrupção da migração. Ele também pode desativar a emulação do TSC (depois de atualizar o valor de TscScale) usando essa MSR.

#define HV_X64_MSR_TSC_EMULATION_CONTROL (0x40000107)
#define HV_X64_MSR_TSC_EMULATION_STATUS (0x40000108)

typedef union
{
    UINT64 AsUINT64;
    struct
    {
        UINT64 Enabled :1;
        UINT64 RsvdZ :63;
    };
 } HV_TSC_EMULATION_CONTROL;

typedef union
{
    UINT64 AsUINT64;
    struct
    {
        UINT64 InProgress : 1;
        UINT64 RsvdP1 : 63;
    };
} HV_TSC_EMULATION_STATUS;

Virtual TLB

O TLB virtual exposto pelo hipervisor pode ser estendido para traduções de cache de GPAs L2 para GPAs. Assim como acontece com o TLB em um processador lógico, o TLB virtual é um cache não coerente e essa não coerência é visível para os convidados. O hipervisor expõe as operações para gerenciar o TLB.

Liberação Virtual Direta

O hipervisor expõe hiperchamas (HvCallFlushVirtualAddressSpace, HvCallFlushVirtualAddressSpaceEx, HvCallFlushVirtualAddressList e HvCallFlushVirtualAddressListEx) que permitem que os sistemas operacionais gerenciem com mais eficiência o TLB virtual. O hipervisor L1 pode optar por permitir que seu convidado use essas hiperchamas e delegar a responsabilidade de tratá-las para o hipervisor L0. Isso requer o uso de uma página de assistência de partição (e um VMCS virtual em plataformas Intel).

Quando em uso, o TLB virtual marca todos os mapeamentos armazenados em cache com um identificador do contexto aninhado (VMCS ou VMCB) que os criou. Em resposta a uma hiperchamada de liberação virtual direta de um convidado L2, o hipervisor L0 invalida todos os mapeamentos em cache criados por contextos aninhados em que

• A VmId é a mesma que a VmId do chamador
• A VpId está contida no ProcessorMask especificado ou HV_FLUSH_ALL_PROCESSORS é especificado

O suporte para liberações virtuais diretas é relatado no 0x4000000A folha CPUID.

Configuração

O tratamento direto de hiperchamadas de liberação virtual é habilitado por:

1. Definindo o campo NestedEnlightenmentsControl.Features.DirectHypercall da Página de Assistência ao Processador Virtual como 1.
2. Definindo o campo IlluminatmentsControl.NestedFlushVirtualHypercall de um VMCS ou VMCB habilitado como 1.

Antes de habilitá-lo, o hipervisor L1 deve configurar os seguintes campos adicionais do VMCS/VMCB habilitado:

• VpId: ID do processador virtual que o VMCS/VMCB habilitado controla.
• VmId: ID da máquina virtual à qual o VMCS/VMCB habilitado pertence.
• PartitionAssistPage: Endereço físico convidado da página de assistência de partição.

O hipervisor L1 também deve expor os seguintes recursos para seus convidados por meio da CPUID.

• UseHypercallForLocalFlush
• UseHypercallForRemoteFlush

Página auxiliar de partição

A página de assistência de partição é uma região de memória alinhada em tamanho de página que o hipervisor L1 deve alocar e zero antes que as hiperchamadas de liberação direta possam ser usadas. Seu GPA deve ser gravado no campo correspondente no VMCS/VMCB habilitado.

struct
{
    UINT32 TlbLockCount;
} VM_PARTITION_ASSIST_PAGE;

VM-Exit sintético

Se o TlbLockCount da página de assistência de partição do chamador não for zero, o hipervisor L0 fornecerá um VM-Exit com um motivo de saída sintético para o hipervisor L1 depois de manipular uma hiperchamada de liberação virtual direta.

Em plataformas Intel, um VM-Exit com motivo HV_VMX_SYNTHETIC_EXIT_REASON_TRAP_AFTER_FLUSH de saída é entregue. Em plataformas AMD, um VM-Exit com código HV_SVM_EXITCODE_ENL de saída é entregue e ExitInfo1 é definido como HV_SVM_ENL_EXITCODE_TRAP_AFTER_FLUSH.

#define HV_VMX_SYNTHETIC_EXIT_REASON_TRAP_AFTER_FLUSH 0x10000031

#define HV_SVM_EXITCODE_ENL 0xF0000000
#define HV_SVM_ENL_EXITCODE_TRAP_AFTER_FLUSH   (1)

Tradução de endereço de segundo nível

Quando a virtualização aninhada está habilitada para uma partição de convidado, a MMU (unidade de gerenciamento de memória) exposta pela partição inclui suporte para tradução de endereço de segundo nível. A tradução de endereço de segundo nível é uma funcionalidade que pode ser usada pelo hipervisor L1 para virtualizar a memória física. Quando em uso, determinados endereços que seriam tratados como GPAs (endereços físicos convidados) são tratados como endereços físicos de convidado L2 (GPAs L2) e traduzidos para GPAs atravessando um conjunto de estruturas de paginação.

O hipervisor L1 pode decidir como e onde usar espaços de endereço de segundo nível. Cada espaço de endereço de segundo nível é identificado por um valor de ID de 64 bits definido pelo convidado. Em plataformas Intel, esse valor é o mesmo que o ponteiro EPT. Em plataformas AMD, o valor é igual ao campo VMCB nCR3.

Compatibilidade

A funcionalidade de tradução de endereço de segundo nível exposta pelo hipervisor geralmente é compatível com o suporte de VMX ou SVM para conversão de endereços. No entanto, existem as seguintes diferenças observáveis por convidado:

• Internamente, o hipervisor pode usar tabelas de página de sombra que traduzem GPAs L2 para SPAs. Nessas implementações, essas tabelas de páginas de sombra aparecem para software como TLBs grandes. No entanto, várias diferenças podem ser observáveis. Primeiro, as tabelas de página de sombra podem ser compartilhadas entre dois processadores virtuais, enquanto as TLBs tradicionais são estruturas por processador e são independentes. Esse compartilhamento pode estar visível porque um acesso de página por um processador virtual pode preencher uma entrada de tabela de página de sombra que é posteriormente usada por outro processador virtual.
• Algumas implementações de hipervisor podem usar a proteção interna de gravação de tabelas de páginas convidadas para liberar de forma preguiçosa mapeamentos mmu de estruturas de dados internas (por exemplo, tabelas de páginas de sombra). Isso é arquitetônicamente invisível para o convidado porque as gravações nessas tabelas serão tratadas de forma transparente pelo hipervisor. No entanto, as gravações executadas nas páginas de GPA subjacentes por outras partições ou por dispositivos podem não disparar a liberação de TLB apropriada.
• Em algumas implementações de hipervisor, uma falha de página de segundo nível pode não invalidar mapeamentos armazenados em cache.

Liberações de TLB de segundo nível esclarecidas

O hipervisor também dá suporte a um conjunto de aprimoramentos que permitem que um convidado gerencie o TLB de segundo nível com mais eficiência. Essas operações aprimoradas podem ser usadas de forma intercambiável com operações de gerenciamento TLB herdadas.

O hipervisor dá suporte às seguintes hiperchamadas para invalidar TLBs:

Em plataformas AMD, todas as entradas TLB são marcadas arquitetônicamente com uma ASID (identificador de espaço de endereço). A invalidação do ASID faz com que todos os inteiros TLB associados ao ASID sejam invalidados. Opcionalmente, o hipervisor aninhado pode optar por um "TLB esclarecido" definindo IlluminatedNptTlb como "1" em HV_SVM_ENLIGHTENED_VMCB_FIELDS. Se o hipervisor aninhado optar pela iluminação, as invalidações ASID apenas liberam inteiros TLB derivados da tradução de endereço de primeiro nível (ou seja, o espaço de endereço virtual). Para liberar entradas TLB derivadas da tabela de página aninhada (NPT) e forçar o hipervisor L0 a recriar tabelas de páginas de sombra, as hiperchamadas HvCallFlushGuestPhysicalAddressSpace ou HvCallFlushGuestPhysicalAddressList devem ser usadas.

Exceções de virtualização aninhadas

Em plataformas Intel. o hipervisor L1 pode aceitar a combinação de exceções de virtualização na classe de exceção de falha de página. O hipervisor L0 anuncia o suporte para essa iluminação na folha CPUID de recursos de virtualização aninhada do Hipervisor.

Esse esclarecimento pode ser habilitado definindo VirtualizationException como "1" em HV_NESTED_ENLIGHTENMENTS_CONTROL estrutura de dados na Página de Assistência ao Processador Virtual.

MSRs de virtualização aninhadas

Registro de índice de VP aninhado

O hipervisor L1 expõe um MSR que relata o índice de VP subjacente do processador atual.

MSRs SynIC aninhadas

Em uma partição raiz aninhada, as SEGUINTEs MSRs permitem acesso aos registros SynIC correspondentes do hipervisor base.

Para localizar o índice do processador subjacente, os chamadores devem primeiro usar HV_X64_MSR_NESTED_VP_INDEX.