Le profondità della virtualizzazione Windows (parte 1) — Dove gira davvero il vostro Windows? L'hypervisor e le partizioni
· Go Komura · Windows, Virtualizzazione, Hyper-V, Hypervisor, SLAT, VMBus
Aprendo Informazioni di sistema (msinfo32) su Windows 11 si vede spesso «In esecuzione» nel campo «Sicurezza basata sulla virtualizzazione» — anche su una macchina in cui non si è mai creata una VM.
Quel che significa è il fatto seguente. Su quel PC, il Windows host stesso sta già girando sopra un hypervisor. La «virtualizzazione» non è più una tecnologia solo per chi crea VM in Gestione Hyper-V. Su Windows 11, la sicurezza basata sulla virtualizzazione (VBS) è abilitata per default sulle configurazioni che soddisfano le condizioni — ad esempio un’installazione pulita su hardware compatibile1 — e sia WSL2 sia Windows Sandbox sono costruiti sullo stesso hypervisor Windows. Sotto il Windows che si usa ogni giorno c’è già un altro strato di software.
Questa serie, «Le profondità della virtualizzazione Windows», segue ciò che accade in quello strato, partendo dai fondamenti.
«Le profondità della virtualizzazione Windows» — Tutte e 3 le parti
- Parte 1 (questo articolo): L’hypervisor e le partizioni
Seguiamo dove finisce a girare il Windows host quando si abilita Hyper-V. - Parte 2: Memoria che nemmeno il kernel può vedere — VBS, HVCI e Credential Guard
Seguiamo dove Windows mette i segreti che né un amministratore né il kernel possono leggere. - Parte 3: Macchine virtuali che si avviano in pochi secondi — WSL2, Windows Sandbox e container
Seguiamo, a partire da come si condividono memoria e immagini, perché WSL2 e Sandbox sono leggeri anche se una VM completa è pesante.
La domanda a cui risponde la parte 1 è una sola.
Quando si abilita Hyper-V, dove finisce a girare il Windows host?
I destinatari sono sviluppatori e operatori che usano Hyper-V, WSL2 o Windows Sandbox e vogliono capire dal meccanismo in su cosa gira sotto. I prerequisiti sono Windows 10/11 x64 o un Windows Server attuale (la discussione di ring, VT-x/AMD-V ed EPT/RVI in questo articolo presuppone x64; Arm64 usa un meccanismo diverso come i livelli di eccezione). Lo sfondo richiesto è circa la distinzione tra modalità kernel e modalità utente; non servono esperienza operativa sulle VM né conoscenze di sviluppo di hypervisor. La difficoltà è intermedia. Trattiamo il concetto di estensioni di virtualizzazione della CPU, ma non entriamo nei dettagli del set di istruzioni.
1. Prima di tutto, la conclusione
Quando si sente Hyper-V, si può immaginare «software per eseguire VM che sta sopra Windows». La struttura reale è l’inverso.
Dal momento in cui si abilita Hyper-V e si riavvia, è l’hypervisor a controllare CPU e memoria fisiche, e il Windows host gira sopra di esso come prima partizione privilegiata — la «partizione root».
Un hypervisor è un sottile strato di software che sta tra l’hardware e il sistema operativo, crea ambienti di esecuzione isolati chiamati «partizioni» e media l’accesso all’hardware.2 Quella in cui entra il Windows host è la partizione root; quelle in cui entrano le VM sono le partizioni figlie. La partizione root è trattata in modo speciale (ha accesso diretto ai dispositivi fisici e detiene lo stack di gestione), ma nel senso che non controlla direttamente le CPU fisiche sta nella stessa posizione di una partizione figlia.
flowchart TB
accTitle: Struttura complessiva dopo l'abilitazione di Hyper-V
accDescr: L'hypervisor sta direttamente sull'hardware fisico, e sopra di esso stanno la partizione root che detiene il Windows host e le partizioni figlie che detengono le VM
hw["Hardware fisico"] --> hv["Hypervisor"]
hv --> root["Partizione root（Windows host）"]
hv --> child1["Partizioni figlie（VM）"]
root -.-> stack["Detiene stack di gestione e driver"]
Figura 1: Hyper-V non è «software VM sopra Windows» ma uno strato che va sotto Windows, e il sistema operativo host stesso gira dentro la partizione root.
Si potrebbe pensare: «Se dopo averlo abilitato non si sente differenza, è davvero avvenuta un’inversione così grande?» Sì. È proprio per questo che di solito questa struttura passa inosservata. In questo articolo smontiamo questo unico diagramma lungo tre assi: CPU, memoria e I/O dei dispositivi.
2. Dalla CPU — Un altro privilegio sotto i ring
2.1. Un ripasso della protezione a ring
Le CPU x64 hanno livelli di privilegio (ring), e Windows gira in modalità kernel a ring 0 e in modalità utente a ring 3. Le applicazioni non possono toccare l’hardware direttamente perché le istruzioni privilegiate non si possono eseguire da ring 3.
Allora come si ospitano in sicurezza più kernel di sistema operativo, ciascuno in esecuzione a ring 0, sulla stessa CPU fisica? Ogni kernel è scritto nell’ipotesi che «io controllo la CPU». Dare ring 0 a tutti e si scontrano; toglierlo e non girano.
flowchart TB
accTitle: Il problema di più kernel OS che pretendono ring 0
accDescr: Sia il kernel host sia quello guest sono scritti presupponendo piena autorità a ring 0, quindi la scala dei ring tradizionale da sola non può ospitarli in sicurezza sulla stessa CPU fisica
k1["Kernel host（presume ring 0）"] --> want["Pretende il controllo della CPU"]
k2["Kernel guest（presume ring 0）"] --> want
want --> conflict["I ring tradizionali non conciliano"]
conflict --> need["Serve un mediatore sopra ring 0"]
Figura 2: La scala dei ring è stata costruita presupponendo un solo sistema operativo, quindi ospitare più kernel richiede un altro privilegio sopra di essa.
2.2. Estensioni di virtualizzazione — Una modalità riservata all’hypervisor
Ciò che risolve questo problema sono le estensioni di virtualizzazione della CPU (Intel VT-x/AMD-V). Hyper-V richiede un processore che abbia questa funzione.2 Le estensioni di virtualizzazione aggiungono, su un asse distinto dai ring tradizionali, una «modalità di esecuzione per l’hypervisor» e una «modalità di esecuzione per i guest». È un privilegio ancora più forte di ring 0, a volte soprannominato «ring -1».
- Il kernel guest continua a girare a ring 0, come prima. Non serve una riscrittura.
- Quel ring 0, però, è «ring 0 dentro la modalità guest», e non controlla la CPU fisica nel suo insieme.
- Quando il guest incontra una particolare operazione che richiede l’intervento dell’hypervisor (un’istruzione configurata come intercept, oppure un’eccezione o una violazione), la CPU trasferisce automaticamente il controllo all’hypervisor (un VM Exit). Quando l’hypervisor ha finito di gestirlo, torna al guest (un VM Entry). Gli accessi ordinari alla memoria passano senza VM Exit, purché la traduzione SLAT riesca.
Le interruzioni funzionano allo stesso modo. Le partizioni non toccano i processori fisici direttamente; l’hypervisor riceve le interruzioni e le indirizza a ciascuna partizione.2
flowchart TB
accTitle: Il flusso dell'esecuzione guest e del VM Exit
accDescr: Il kernel guest e le app girano a ring 0 e ring 3 in modalità guest; gli accessi ordinari alla memoria passano tramite traduzione SLAT, mentre intercept ed eccezioni configurati provocano un VM Exit che trasferisce il controllo all'hypervisor, il quale poi torna al guest tramite VM Entry
guest["In esecuzione in modalità guest（incluso un kernel ring 0）"] --> op{"Operazione che richiede intervento?（intercept/eccezioni）"}
op -->|No| cont["Continua l'esecuzione così com'è"]
op -->|Sì| exitEv["VM Exit（la CPU trasferisce il controllo）"]
exitEv --> hvp["L'hypervisor lo gestisce"]
hvp --> entry["Ritorno al guest via VM Entry"]
entry --> guest
Figura 3: Il sistema operativo guest continua a girare a ring 0 senza riscrittura, e la CPU chiama l’hypervisor solo quando serve.
Questo andata e ritorno assomiglia molto al flusso seguito nella serie sulla memoria — «entra nel kernel su un page fault, poi torna alla stessa istruzione». La CPU intercetta il controllo tramite un meccanismo di eccezione o transizione, lascia decidere a un gestore di livello superiore e poi torna. Nelle profondità di Windows, questa forma compare di nuovo e di nuovo.
2.3. Tipo 1 e tipo 2 — La differenza è dove sta
Gli hypervisor si dividono in larga misura in tipo 1 (bare-metal), che gira direttamente sull’hardware, e tipo 2 (hosted), che gira sopra un sistema operativo host. Hyper-V è di tipo 1.3 VirtualBox e VMware Workstation (quando girano in autonomia) sono classificati come tipo 2.
Sentendo tipo 1, si tende a immaginare «una configurazione solo server senza sistema operativo host», ma Hyper-V è diverso. Il Windows host non scompare: «si trasferisce» nella partizione root. Quando si abilita Hyper-V e si riavvia, l’hypervisor parte per primo durante l’avvio, e il Windows host poi sale come partizione root sopra di esso.
flowchart TB
accTitle: La differenza tra hypervisor di tipo 1 e di tipo 2
accDescr: Nel tipo 2 il sistema operativo host sta sull'hardware e l'hypervisor e le VM stanno sul sistema operativo host, mentre nel tipo 1 Hyper-V l'hypervisor sta direttamente sull'hardware e il sistema operativo host stesso entra nella partizione root sopra di esso
subgraph t2 ["Tipo 2（hosted）"]
hw2["Hardware"] --> hostos["Sistema operativo host"]
hostos --> hv2["Hypervisor"]
hv2 --> vm2["VM"]
end
subgraph t1 ["Tipo 1（Hyper-V）"]
hw1["Hardware"] --> hv1["Hypervisor"]
hv1 --> root1["Partizione root（SO host）"]
hv1 --> vm1["VM"]
end
vm2 ~~~ hw1
Figura 4: Nel tipo 2 l’hypervisor sta sul sistema operativo host, mentre nel tipo 1 Hyper-V l’ordine è invertito e il sistema operativo host stesso sta sullo strato un gradino sotto.
Visto su una linea temporale di avvio, il cambiamento che avviene quando lo si abilita è questo.
flowchart TB
accTitle: Ordine di avvio dopo l'abilitazione di Hyper-V
accDescr: Dopo l'accensione, l'hypervisor parte per primo durante l'avvio, il Windows host poi sale come partizione root sopra di esso, e VM, VBS e simili partono dopo
poweron["Accensione e inizio avvio"] --> bhv["L'hypervisor parte per primo"]
bhv --> broot["Windows host parte come partizione root"]
broot --> blater["VM, VBS, WSL2 e simili partono sopra"]
broot -.-> feel["L'esperienza utente non cambia"]
Figura 5: L’inversione dell’ordine è già finita prima che appaia la schermata di accesso, e il sistema operativo host sale sull’hypervisor fin dall’inizio.
3. Le partizioni — L’unità di isolamento
3.1. Ruoli che ha solo la partizione root
Una partizione è un’unità logica di isolamento che l’hypervisor fornisce.2 Non tutte le partizioni sono uguali, però. Ci sono cose che ha solo la partizione root.
- Accesso diretto ai dispositivi fisici. I driver di dispositivo per dischi, NIC, GPU e simili vivono nel Windows dentro la partizione root, non nell’hypervisor. Hyper-V su Windows Server ha una configurazione che assegna un dispositivo PCIe specifico direttamente a una partizione figlia (Discrete Device Assignment); in quel caso la root lascia andare quel dispositivo (non è disponibile sul Windows client).4
- Lo stack di gestione della virtualizzazione. VMMS (Virtual Machine Management Service), che governa creazione, avvio e arresto delle VM, e il processo worker per VM (vmwp.exe) girano in modalità utente nella partizione root.5 Questi fanno parte delle funzioni di gestione VM di Hyper-V, quindi possono essere assenti su un host in cui gira solo l’hypervisor per VBS o WSL2.
- Il diritto di creare partizioni figlie. La partizione root crea partizioni figlie tramite l’API hypercall (l’interfaccia di chiamata verso l’hypervisor).2
Questo progetto ha una ragione. Se si mettessero tutti i driver di dispositivo nell’hypervisor stesso, l’hypervisor diventerebbe enorme e crescerebbe il numero di bug e di punti di ingresso per gli attacchi. L’hypervisor si limita al lavoro minimo di mediare CPU e memoria, e lascia la cura dei dispositivi al Windows nella partizione root. Questa divisione dei ruoli è ciò che tiene Hyper-V sottile.
flowchart TB
accTitle: Divisione dei ruoli tra partizione root e partizioni figlie
accDescr: La partizione root detiene lo stack di gestione della virtualizzazione e i driver dei dispositivi fisici e crea partizioni figlie via hypercall; una partizione figlia di norma vede solo dispositivi virtuali, e sotto Discrete Device Assignment su Windows Server accede direttamente al dispositivo assegnato
subgraph rootp ["Partizione root"]
vmms["VMMS e processi worker"]
drv["Driver dei dispositivi fisici"]
end
subgraph childp ["Partizione figlia"]
gos["Sistema operativo guest"]
vdev["Di solito solo dispositivi virtuali"]
end
vmms -->|Crea e gestisce via hypercall| childp
hv2["Hypervisor（si limita a mediare CPU e memoria）"] --- rootp
hv2 --- childp
Figura 6: Mettere i driver di dispositivo e lo stack di gestione sul lato della partizione root è ciò che tiene sottile l’hypervisor stesso.
3.2. Il mondo visto da una partizione figlia
Il sistema operativo guest in una partizione figlia non può vedere l’hardware fisico direttamente nella configurazione usuale a dispositivi virtuali (l’unica eccezione è un dispositivo assegnato via Discrete Device Assignment su Windows Server, come descritto nella sezione precedente). Ciò che può vedere sono processori virtuali, uno spazio di memoria che appare suo, e dispositivi virtuali. Le richieste ai dispositivi virtuali vengono inoltrate alla partizione root via VMBus o l’hypervisor.2 L’allocazione del tempo CPU e la traduzione della memoria via SLAT, invece, sono gestite direttamente dall’hypervisor senza passare dalla root. Ciò che la root media è l’I/O dei dispositivi, non ogni risorsa fisica.
flowchart TB
accTitle: Il mondo visto da una partizione figlia
accDescr: Ciò che il sistema operativo guest vede sono processori virtuali, uno spazio di memoria privato della partizione e dispositivi virtuali; le richieste ai dispositivi virtuali vengono inoltrate alla partizione root via VMBus e simili, tempo CPU e traduzione della memoria sono gestiti direttamente dall'hypervisor, e in una configurazione Discrete Device Assignment su Windows Server solo i dispositivi assegnati sono accessibili direttamente
gos2["SO guest（figlia）"] --> vcpu["Processori virtuali"]
gos2 --> rest{"Memoria o dispositivi?"}
rest --> gpa2["Spazio di memoria privato"]
rest --> vdev2["Dispositivi virtuali"]
vdev2 --> rootx["Inoltrato alla root"]
rootx -.-> vbus["Via VMBus e simili"]
gos2 -.-> phys2["CPU, RAM, dispositivi fisici"]
phys2 -.-> hid["Non visibili direttamente"]
phys2 -.-> dda2["DDA: dispositivi assegnati"]
dda2 -.-> ddaN["Windows Server"]
vcpu ~~~ phys2
Figura 7: Nella configurazione usuale a dispositivi virtuali tutto ciò che il guest vede è una finestra virtuale e il percorso verso il fisico passa da un mediatore; solo un dispositivo assegnato via DDA su Windows Server è l’eccezione.
Quel che importa qui è che per un’app che gira sul Windows host, questa struttura è quasi trasparente. Le chiamate alle API Win32 e la gestione dei page fault sono ancora elaborate dal kernel Windows dentro la partizione root, come prima. L’hypervisor interviene solo quando si incontra un intercept o un’eccezione configurati.
4. Dalla memoria — La traduzione degli indirizzi guadagna un altro livello
4.1. Tre tipi di indirizzo
Nella parte 1 della serie sulla memoria abbiamo seguito il flusso con cui un indirizzo virtuale viene tradotto attraverso la page table in un indirizzo fisico («Il momento in cui un indirizzo virtuale diventa RAM fisica»). In un ambiente virtualizzato sotto quella traduzione si aggiunge un altro livello, e ci sono tre tipi di indirizzo.
| Indirizzo | Abbreviazione | Chi lo gestisce |
|---|---|---|
| Indirizzo virtuale guest | GVA | La page table del sistema operativo guest |
| Indirizzo fisico guest | GPA | L’indirizzo che il sistema operativo guest crede «fisico» |
| Indirizzo fisico di sistema | SPA | L’hypervisor (la posizione reale in RAM) |
Il sistema operativo guest traduce GVA in GPA con la propria page table. Il GPA che il guest vede, però, non è un indirizzo fisico reale; è uno spazio di memoria privato dedicato a ciascuna partizione.2 Mappare il GPA sulla posizione reale in RAM (SPA) è il lavoro dell’hypervisor.
4.2. SLAT — Traduzione a due livelli in hardware
Se si fa questa traduzione di secondo livello solo in software, l’hypervisor deve seguire uno per uno ogni aggiornamento della page table del guest, il che non è realistico dal punto di vista delle prestazioni. Quindi la CPU fornisce un meccanismo che percorre le tabelle di traduzione di secondo livello in hardware. Quello è SLAT (Second Level Address Translation); Intel EPT (Extended Page Tables) e AMD RVI ne sono le implementazioni. L’Hyper-V attuale richiede un processore a 64 bit capace di SLAT.4
flowchart TB
accTitle: Traduzione degli indirizzi a due livelli via SLAT
accDescr: Un indirizzo virtuale guest viene tradotto in un indirizzo fisico guest dalla page table del sistema operativo guest, poi ulteriormente tradotto in un indirizzo fisico di sistema da SLAT, che l'hypervisor gestisce, e raggiunge la RAM reale
gva["Indirizzo virtuale guest（GVA）"] -->|Page table del SO guest| gpa["Indirizzo fisico guest（GPA）"]
gpa -->|"SLAT（tabelle EPT/RVI）"| spa["Indirizzo fisico di sistema（SPA）"]
spa --> ram["RAM fisica"]
gpa -.-> note["Uno strato che il guest crede fisico"]
Figura 8: Un’altra tabella di traduzione, gestita dall’hypervisor, sta sotto la page table del guest, e la CPU percorre entrambe in hardware.
SLAT non è una funzione che esiste solo per l’efficienza di esecuzione delle VM. Il VBS che vedremo nella parte 2 usa la proprietà che «si può avere una tabella di traduzione SLAT diversa per livello di privilegio» come materiale per un confine di sicurezza. La ragione per cui si può creare memoria che nemmeno il kernel può vedere è che l’hypervisor detiene questa traduzione di secondo livello. Questo diventa un filo conduttore per l’intera serie, quindi basta ricordare un punto: «il proprietario delle tabelle di traduzione è l’hypervisor».
5. Dall’I/O dei dispositivi — VMBus e due tipi di dispositivo
5.1. I limiti dei dispositivi emulati
Il modo classico di mostrare un dispositivo a una partizione figlia è imitare per intero l’hardware reale (ad esempio un vecchio controller IDE) in software. La compatibilità è alta perché i driver inbox del sistema operativo guest funzionano così come sono, ma un VM Exit avviene ogni volta che il guest tocca una porta I/O, e le prestazioni non scalano.
flowchart TB
accTitle: Perché l'I/O verso un dispositivo emulato è lento
accDescr: Ogni volta che il guest opera una porta I/O, il controllo passa al lato hypervisor via VM Exit, il dispositivo viene imitato in software e si torna al guest, quindi l'andata e ritorno si ripete ed è lento
gio["Il guest opera una porta I/O"] --> vex["Avviene un VM Exit"]
vex --> emu2["Il dispositivo è emulato in software"]
emu2 --> back["Ritorno al guest via VM Entry"]
back -->|Si ripete alla prossima operazione| gio
Figura 9: Questo andata e ritorno gira molte volte dietro un singolo accesso a disco, e il prezzo della compatibilità si paga in prestazioni.
5.2. VMBus e VSP/VSC — Un percorso veloce progettato per la virtualizzazione
Quindi Hyper-V ha un meccanismo di «dispositivo sintetico» progettato nell’ipotesi della virtualizzazione. Ci sono tre personaggi.2
- VMBus: un canale di comunicazione logico tra partizioni. Fornisce comunicazione ad alta velocità tra partizioni che usa memoria condivisa.3
- VSP (Virtualization Service Provider): un servizio che risiede sul lato della partizione root, riceve le richieste di dispositivo dalla figlia e le ponte verso lo stack dispositivo/backend sul lato root. Una richiesta può raggiungere un dispositivo fisico, o può essere gestita da un backend lato host come un disco virtuale o uno switch virtuale.
- VSC (Virtualization Service Consumer): un driver di dispositivo sintetico che va nel sistema operativo guest sul lato della partizione figlia. Invia le richieste al VSP su VMBus.
Prendendo come esempio una richiesta di storage del sistema operativo guest, il flusso è questo. Il WriteFile dell’app guest scende nello stack I/O del kernel guest e, in fondo, raggiunge il VSC (invece dell’hardware reale). Il VSC mette la richiesta su VMBus e la consegna al VSP nella partizione root, e il VSP fa fluire la richiesta nello stack I/O lato root. In una configurazione a disco virtuale (VHDX), questa scrittura viene gestita come una scrittura su un file VHDX sull’host e alla fine raggiunge il disco fisico. Questo approccio si chiama Enlightened I/O (I/O consapevole della virtualizzazione), e alza l’efficienza aggirando lo strato di emulazione del dispositivo.2
flowchart TB
accTitle: Percorso I/O di un dispositivo sintetico
accDescr: Una richiesta I/O da un'app nella partizione figlia raggiunge il VSC attraverso il kernel guest, attraversa VMBus fino al VSP nella partizione root, e sullo stack I/O lato root in cui il VSP la ponte può raggiungere un dispositivo reale via un driver di dispositivo fisico, o può essere gestita da un backend lato host come un disco virtuale o uno switch virtuale
app["App nella partizione figlia"] --> gk["Stack I/O del kernel guest"]
gk --> vsc["VSC（driver di dispositivo sintetico）"]
vsc -->|VMBus| vsp["VSP（lato partizione root）"]
vsp --> rio["Stack I/O lato root"]
rio --> pdrv["Driver di dispositivo fisico"]
rio --> hb["Backend lato host（disco virtuale, switch virtuale, ecc.）"]
pdrv --> dev["Dispositivo fisico"]
Figura 10: Con un dispositivo sintetico, l’I/O del guest attraversa fino alla partizione root su VMBus e, attraverso lo stack lato root, raggiunge un dispositivo reale o un backend lato host.
In altre parole, se l’I/O disco o la rete di una VM è veloce dipende non solo dal lato guest ma anche dallo stato dello stack I/O e dei driver di dispositivo sul lato della partizione root. La ragione per cui l’osservazione lato host è indispensabile quando si indaga un problema di prestazioni di una VM è che il percorso passa effettivamente dall’host.
flowchart TB
accTitle: Dispositivi emulati rispetto a dispositivi sintetici
accDescr: Un dispositivo emulato imita l'hardware reale così i driver inbox del guest funzionano ma è lento; un dispositivo sintetico è un driver apposito che presuppone VMBus ed è veloce
dev2{"Dispositivo mostrato alla partizione figlia"} --> emu["Dispositivo emulato"]
dev2 --> syn["Dispositivo sintetico"]
emu -.-> emuP["Emula l'hardware reale; compatibilità prima"]
emuP -.-> emuC["Intervento a ogni I/O; lento"]
syn -.-> synP["Progettato attorno a VMBus; veloce"]
synP -.-> synC["Richiede un driver corrispondente nel guest"]
Figura 11: Dei due tipi di dispositivo virtuale, i dispositivi emulati portano la compatibilità subito dopo l’installazione del sistema operativo, e i dispositivi sintetici portano le prestazioni nell’uso quotidiano.
6. Perché non è un problema di altri, anche se non si usa mai una VM
La struttura fin qui può sembrare «una storia per chi alza le VM». Come detto in apertura, però, sul Windows attuale l’hypervisor fa parte della vita quotidiana.
- Sicurezza basata sulla virtualizzazione (VBS). Usa l’hypervisor Windows per creare un ambiente isolato e vi ospita le funzioni di sicurezza. Su Windows 11 è abilitata per default quando si soddisfano condizioni come un’installazione pulita su hardware compatibile.1 I dettagli sono nella parte 2.
- WSL2. Gira un vero kernel Linux dentro una utility VM leggera.6
- Windows Sandbox. Un ambiente Windows usa-e-getta isolato dall’hypervisor.7 Entrambi sono trattati nella parte 3.
flowchart TB
accTitle: Funzioni quotidiane che stanno sullo stesso hypervisor
accDescr: Non solo le VM Hyper-V ma anche VBS, che è abilitata per default sui dispositivi che soddisfano condizioni come un'installazione pulita, più WSL2 e Windows Sandbox, sono tutte costruite sullo stesso hypervisor Windows
base["Hypervisor Windows"] --> f1["VM Hyper-V"]
base --> f2["VBS（abilitata per default su installazioni pulite e simili）"]
base --> f3["WSL2"]
base --> f4["Windows Sandbox"]
f2 -.-> daily["Perché gira anche su PC che non usano mai una VM"]
Figura 12: C’è un solo fondamento, ed è in questa figura che cade l’assunzione «la virtualizzazione è una storia per chi usa le VM».
Un’altra cosa su cui si inciampa spesso in pratica è la coesistenza con software di virtualizzazione di terze parti. Poiché l’hypervisor usa in esclusiva le estensioni di virtualizzazione della CPU, in un ambiente in cui l’hypervisor Windows è in esecuzione VirtualBox e simili non possono girare nel modo tradizionale (il modo che usa esso stesso le estensioni di virtualizzazione della CPU). Per questo è prevista un’API pubblica chiamata Windows Hypervisor Platform, e uno stack di virtualizzazione di terze parti può girare stando sopra l’hypervisor Windows.8 Gli attuali VirtualBox/VMware possono coesistere con WSL2 grazie a questo meccanismo, ma differenze di prestazioni e di funzioni che arrivano con il cambio di modalità si osservano a volte come «dopo aver abilitato Hyper-V (o VBS), il software di virtualizzazione ha iniziato a comportarsi diversamente».
flowchart TB
accTitle: Chi possiede le estensioni di virtualizzazione della CPU, e il percorso per il software di virtualizzazione di terze parti
accDescr: Mentre l'hypervisor Windows è in esecuzione possiede in esclusiva le estensioni di virtualizzazione della CPU; il software di virtualizzazione di terze parti che supporta WHP gira sopra di esso via Windows Hypervisor Platform, mentre le implementazioni che non supportano WHP non possono girare o sono limitate nelle funzioni
vt["Estensioni di virtualizzazione CPU（VT-x/AMD-V）"] --> hvon{"L'hypervisor Windows è in esecuzione?"}
hvon -->|No| direct["Il software di terze parti può usarle direttamente"]
hvon -->|Sì| own["L'hypervisor le usa in esclusiva"]
own --> whp["Windows Hypervisor Platform"]
whp --> third["Il software di terze parti con WHP gira sopra"]
third -.-> nowhp["Le implementazioni senza WHP non girano, o sono limitate"]
Figura 13: C’è un solo proprietario delle estensioni di virtualizzazione, e l’unico software di terze parti che può coesistere mentre l’hypervisor è in esecuzione è il software che supporta l’API pubblica (WHP).
7. Verificatelo voi stessi
Si può confermare sulla propria macchina se un hypervisor è in esecuzione.
Prima, un controllo che si può eseguire senza privilegi di amministratore.
# Whether we are running on top of a hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent
# VBS status (same source as "Virtualization-based security" in msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
-ClassName Win32_DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus
VirtualizationBasedSecurityStatus restituisce lo stato di esecuzione di VBS come numero (2 è «In esecuzione»).9
Un’accortezza. Tutto ciò che HypervisorPresent dice è «se stiamo girando sopra un hypervisor»; non distingue root da figlia. Se lo si esegue su Windows dentro una VM, restituisce comunque True, come partizione figlia. Se è True su Windows su un PC fisico, quel Windows è dentro la partizione root: lo si legge insieme all’ambiente di esecuzione.
Poi, il classico da un prompt dei comandi.
systeminfo
Guardare «Hyper-V Requirements» in fondo all’output. Su una macchina in cui l’hypervisor non è ancora in esecuzione, sono elencati i requisiti singoli — supporto SLAT, se le estensioni di virtualizzazione sono abilitate, e così via. Su una macchina in cui l’hypervisor è già in esecuzione, al posto dei requisiti si ottiene una sola riga: «A hypervisor has been detected. Features required for Hyper-V will not be displayed.»4 Quella riga è quindi un’affermazione che il vostro Windows sta girando sopra qualche hypervisor. Come per HypervisorPresent, va letta come «dentro la partizione root» su un PC fisico, o «come partizione figlia» dentro una VM.
Anche se ogni requisito di systeminfo è «Yes», significa solo che il lato hardware è pronto. La funzione Hyper-V stessa è disponibile sulle edizioni Pro, Enterprise ed Education, e non lo è su Home.10
Nella GUI, controllare la riga «Sicurezza basata sulla virtualizzazione» in «Riepilogo sistema» di msinfo32. Si noti che «Virtualizzazione: abilitata» nel riquadro CPU di Gestione attività mostra solo se le estensioni di virtualizzazione sono abilitate nel firmware, che è un’informazione distinta da se un hypervisor è in esecuzione.
flowchart TB
accTitle: Come verificare se l'hypervisor è in esecuzione
accDescr: Se systeminfo dice che è stato rilevato un hypervisor si sta girando su un hypervisor (dentro la partizione root su un PC fisico); se compare l'elenco Hyper-V Requirements non è ancora in esecuzione quindi si controllano tutti i requisiti come SLAT, VM Monitor Mode Extensions e DEP, ma tutti Yes significano solo che il lato hardware è pronto e la funzione Hyper-V ha anche un requisito di edizione
start2["Esegui systeminfo"] --> q1{"Campo Requirements?"}
q1 -->|Rilevato| running["L'hypervisor è in esecuzione"]
running -.-> runN["Dentro la root"]
runN -.-> runN2["su un PC fisico"]
q1 -->|Elencato| notyet["Non ancora in esecuzione"]
notyet --> q2{"Tutti i requisiti Yes?"}
q2 -->|Tutti Yes| can["Il lato hardware è pronto"]
can -.-> ed["Serve Pro / Ent / Edu"]
q2 -->|Qualche No| uefi["Controlla le voci UEFI/BIOS"]
Figura 14: Il campo «Hyper-V Requirements» di systeminfo funge sia da controllo dello stato di esecuzione sia da controllo dei prerequisiti.
8. Tre equivoci da evitare nella pratica
8.1. «Non abbiamo abilitato Hyper-V, quindi la virtualizzazione non c’entra con i nostri PC»
Anche se non si è abilitata la funzione Hyper-V (gli strumenti di gestione e l’ambiente di esecuzione delle VM), l’hypervisor Windows è in esecuzione se VBS è abilitata. Quando si indaga un problema di compatibilità di un driver, un test di prestazioni o un guaio con software di virtualizzazione di terze parti, controllare HypervisorPresent e lo stato di esecuzione di VBS — non se la funzione è abilitata.
8.2. «Gestione attività dice “Virtualizzazione: abilitata”, quindi Hyper-V è in esecuzione»
Quella visualizzazione riguarda l’impostazione del firmware (se VT-x/AMD-V è disponibile). Giudicare lo stato di esecuzione dell’hypervisor da «A hypervisor has been detected» in systeminfo. Viceversa, se Gestione attività dice «Disabilitata», non si possono abilitare né Hyper-V né WSL2, quindi controllare prima le impostazioni UEFI/BIOS.
flowchart TB
accTitle: Tre controlli facili da confondere
accDescr: Il campo Virtualizzazione di Gestione attività mostra l'impostazione del firmware, l'elenco Funzionalità di Windows mostra lo stato di installazione, e systeminfo o HypervisorPresent mostrano lo stato di esecuzione; ciascuno risponde a una domanda diversa
q3{"Quale domanda?"}
q3 --> fw{"Firmware o Windows?"}
q3 --> c3["L'hypervisor è in esecuzione?"]
fw --> a3["Estensioni firmware?"]
fw --> b3["Funzione Hyper-V attiva?"]
a3 -.-> a3t["Riquadro CPU di Gestione attività"]
b3 -.-> b3t["UI Funzionalità di Windows"]
c3 -.-> c3t["systeminfo"]
c3 -.-> c3tp["HypervisorPresent"]
Figura 15: Sono tre domande indipendenti, e inferire le altre due da una sola visualizzazione è un equivoco.
8.3. «Se la VM è lenta, è un problema del sistema operativo guest»
L’I/O dei dispositivi sintetici attraversa VMBus fino al VSP nella partizione root e passa dallo stack dispositivo/backend lato root (driver fisici, più l’elaborazione di switch virtuale e disco virtuale). Se si guardano solo i contatori dentro il guest, non si trova un collo di bottiglia che sta nello storage lato host o in una NIC. Il principio per i problemi di prestazioni delle VM è osservare da entrambi i lati: il guest e l’host (la partizione root).
9. Riepilogo
- Quando si abilita Hyper-V, l’hypervisor gira direttamente sull’hardware e il Windows host gira come partizione root.2
- Il kernel del sistema operativo guest continua a girare a ring 0, e solo le operazioni configurate come intercept, più le eccezioni, vengono consegnate all’hypervisor via VM Exit. Gli accessi ordinari alla memoria passano via traduzione SLAT.
- Solo la partizione root detiene i driver dei dispositivi fisici e lo stack di gestione della virtualizzazione, e crea partizioni figlie via hypercall.2
- La memoria diventa una traduzione a due livelli GVA→GPA→SPA, e il secondo livello è gestito in hardware da SLAT (EPT/RVI). L’Hyper-V attuale richiede SLAT.4
- L’I/O dei dispositivi è dominato dal percorso di dispositivo sintetico VSC→VMBus→VSP, e le prestazioni dipendono anche dallo stack I/O lato host.2
- Su Windows 11, poiché VBS è abilitata per default sui dispositivi che soddisfano condizioni come un’installazione pulita, non è insolito che l’hypervisor sia in esecuzione anche su un PC che non usa mai una VM.1 Si può confermare lo stato di esecuzione con
HypervisorPresente systeminfo.
Il quadro d’insieme della parte 1 si condensa in questo unico diagramma.
flowchart TB
accTitle: Il quadro d'insieme della parte 1
accDescr: L'hypervisor sta sotto la partizione root e le partizioni figlie; le CPU sono allocate schedulando processori virtuali (VM Exit solo su intercept ed eccezioni configurati), la memoria è mediata dalla traduzione SLAT a due livelli, l'I/O dei dispositivi sintetici è inoltrato su VMBus e gestito dal VSP della partizione root, e i dispositivi emulati e Discrete Device Assignment hanno altri percorsi
up["Partizioni root + figlie"] --> hvS["Hypervisor"]
hvS --> cpuS["CPU: schedula i VP"]
hvS --> memS["Memoria: SLAT"]
cpuS -.-> cpuN["VM Exit su intercept"]
memS -.-> memN["Traduzione a due livelli"]
memS ~~~ devS
devS["Dispositivi: I/O VMBus"] --> vspS["Il VSP lato root gestisce"]
devS -.-> devN["Emulati / DDA: altri"]
Figura 16: Lo scheduling della CPU e la traduzione della memoria sono gestiti direttamente dall’hypervisor (VM Exit solo in caso di intervento), e l’I/O dei dispositivi sintetici è mediato dalla partizione root (il VSP) al di là di VMBus.
Continua nella parte 2, «Memoria che nemmeno il kernel può vedere — VBS, HVCI e Credential Guard».
Riprendiamo il filo conduttore di questo articolo — che l’hypervisor detiene le tabelle di traduzione SLAT — e seguiamo come Windows crea «memoria che né un amministratore né il kernel possono leggere».
Articoli correlati
- Le profondità della memoria Windows (parte 1) — Il momento in cui un indirizzo virtuale diventa RAM fisica: un page fault dall’inizio alla fine
- Cosa significa davvero l’«uso della memoria» di Windows? — Leggere correttamente Working Set, Private Bytes, Commit e il file di paging
- Come accelerare la convalida delle app con Windows Sandbox
- Impostazioni di scheduling del processore Windows - Background services e P/E core
Aree di consulenza correlate
KomuraSoft LLC si occupa di progettazione di ambienti di convalida per applicazioni Windows, di indagini sulle prestazioni in ambienti virtualizzati e di analisi di problemi di compatibilità di driver e periferiche.
- Sviluppo di app Windows
- Indagine sui difetti e analisi delle cause
- Riutilizzo di asset esistenti e supporto alla migrazione
- Contattaci
Riferimenti
-
Microsoft Learn, Silicon assisted security. Sul fatto che VBS usi la virtualizzazione hardware per isolare il Secure Kernel dal sistema operativo ordinario, e sul fatto che VBS e HVCI siano abilitate per default sui dispositivi che soddisfano i prerequisiti a una nuova installazione di Windows 11. ↩ ↩2 ↩3
-
Microsoft Learn, Hyper-V Architecture. Sul fatto che l’hypervisor fornisca le partizioni come unità di isolamento; che la partizione root crei partizioni figlie via API hypercall; che le partizioni girino in uno spazio di memoria virtuale privato senza accesso diretto ai processori fisici; sui ruoli di VMBus, VSP, VSC ed Enlightened I/O; e sul fatto che siano richieste le estensioni di virtualizzazione hardware (Intel VT/AMD-V). ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
-
Microsoft Learn, Hyper-V architecture (Performance Tuning). Sul fatto che Hyper-V sia un hypervisor di tipo 1, che la partizione root possieda i dispositivi I/O fisici, e che VMBus fornisca comunicazione ad alte prestazioni tra partizioni che usa memoria condivisa. ↩ ↩2
-
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. Sul fatto che siano richiesti un processore a 64 bit capace di SLAT e VM Monitor Mode Extensions; sulla possibilità di confermare che i requisiti siano soddisfatti nel campo «Hyper-V Requirements» di systeminfo; sul fatto che venga visualizzato «A hypervisor has been detected» mentre un hypervisor è in esecuzione; e sul fatto che Discrete Device Assignment possa assegnare un dispositivo specifico direttamente a una partizione figlia. ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. Sul fatto che VMMS (Virtual Machine Management Service) gestisca lo stato delle VM nelle partizioni figlie, e che un processo worker (VMWP) parta in modalità utente nella partizione root per ciascuna VM. ↩
-
Microsoft Learn, Comparing WSL Versions. Sul fatto che WSL2 giri un vero kernel Linux dentro una utility VM leggera, e sulle accortezze nell’usarlo insieme agli attuali VMware e VirtualBox. ↩
-
Microsoft Learn, Windows Sandbox architecture. Sul fatto che Windows Sandbox sia un ambiente Windows leggero che combina la tecnologia dei container con l’isolamento da parte dell’hypervisor. ↩
-
Microsoft Learn, Windows Hypervisor Platform. Sul fatto che sia prevista un’API in modalità utente così che uno stack di virtualizzazione di terze parti possa creare e gestire partizioni sopra l’hypervisor Windows. ↩
-
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. Sul fatto di poter confermare lo stato di esecuzione di VBS (virtual secure mode) tramite VirtualizationBasedSecurityStatus sulla classe Win32_DeviceGuard. ↩
-
Microsoft Learn, Install Hyper-V. Sul fatto che Hyper-V sia abilitabile su Windows 10/11 Pro o Enterprise e simili, e non sia installabile sull’edizione Home. ↩
Articoli correlati
Articoli recenti con gli stessi tag per approfondire argomenti vicini.
Le profondità della virtualizzazione Windows (parte 3) — Macchine virtuali che si avviano in pochi secondi: perché WSL2, Windows Sandbox e i container sono così leggeri
Perché WSL2 e Windows Sandbox partono in pochi secondi e sembrano così leggeri? Questo articolo spiega i meccanismi, dalle immagini di ba...
Le profondità della virtualizzazione Windows (parte 2) — Memoria che nemmeno il kernel può vedere: come funzionano VBS, HVCI e Credential Guard
Su un'installazione pulita su hardware compatibile, VBS è abilitata per default e usa l'hypervisor e SLAT per creare un isolamento più fo...
L'API thread pool Win32 — Concorrenza senza creare thread, tramite CreateThreadpoolWork
State spargendo chiamate CreateThread per tutto il codice nativo? Questo articolo spiega l'API thread pool Win32 ridisegnata in Vista — i...
Named pipe in pratica — L'IPC standard di Windows, dalla progettazione alla sicurezza
Guida pratica alle named pipe, il meccanismo standard di comunicazione tra processi su Windows. L'articolo organizza, a partire dalle fon...
Come comprendere l'isolamento delle sessioni di Windows — Session 0, RDP ed esecuzione simultanea di più utenti
Questo articolo chiarisce il concetto di «sessione» di Windows, un argomento che genera costante confusione tra gli sviluppatori di appli...
Argomenti correlati
Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.
Argomenti tecnici Windows
Portale su sviluppo Windows, analisi dei problemi e valorizzazione delle risorse esistenti.
Servizi collegati all’argomento
L’articolo è direttamente collegato ai servizi seguenti.
Sviluppo di applicazioni Windows
Applicazioni aziendali, integrazione di dispositivi e strumenti di comunicazione, dai requisiti allo sviluppo.
Domande frequenti
Domande che ricorrono nelle consulenze sull’argomento dell’articolo.
- Quando si abilita Hyper-V, dove gira davvero il Windows host?
- L'hypervisor prende il controllo diretto di come vengono allocati CPU e memoria fisiche, e il Windows host gira dentro una partizione speciale chiamata partizione root. Il controllo dei dispositivi fisici è di norma gestito dai driver sul lato della partizione root. La partizione root detiene i driver di dispositivo e lo stack di gestione della virtualizzazione, ma la proprietà delle CPU fisiche appartiene all'hypervisor.
- «Virtualizzazione: abilitata» in Gestione attività significa che Hyper-V è in esecuzione?
- No. Quella visualizzazione indica se le estensioni di virtualizzazione della CPU (Intel VT-x/AMD-V) sono abilitate nel firmware. Per vedere se un hypervisor è effettivamente in esecuzione, cercare «A hypervisor has been detected» in systeminfo, oppure controllare Win32_ComputerSystem.HypervisorPresent.
- Perché l'hypervisor è in esecuzione anche se non ho mai creato una VM?
- Su Windows 11, la sicurezza basata sulla virtualizzazione (VBS) è abilitata per default sui dispositivi che soddisfano le condizioni — ad esempio un'installazione pulita su hardware compatibile — e VBS è costruita sull'hypervisor Windows. Lo stesso vale se si usa WSL2 o Windows Sandbox. Non è insolito che l'hypervisor sia in esecuzione senza alcun legame con chi usa le VM.
- Cos'è SLAT, e perché è richiesto per Hyper-V?
- SLAT (Second Level Address Translation) è il meccanismo con cui la CPU traduce gli indirizzi fisici guest in indirizzi fisici reali; Intel EPT e AMD RVI ne sono le implementazioni. Senza di esso l'hypervisor dovrebbe mantenere le tabelle di traduzione in software, il che non è realistico dal punto di vista delle prestazioni, quindi l'Hyper-V attuale lo tratta come un requisito vincolante.
- Se abilito Hyper-V, VirtualBox e VMware smetteranno di funzionare?
- Poiché l'hypervisor usa in esclusiva le estensioni di virtualizzazione della CPU, un hypervisor di terze parti non può girare nel modo tradizionale. Gli attuali VirtualBox e VMware, però, hanno una modalità che gira sopra l'hypervisor Windows (tramite Windows Hypervisor Platform), quindi le versioni recenti di ciascuno possono coesistere.
Profilo dell’autore
Pagina di presentazione dell’autore dell’articolo.
Go Komura
Rappresentante di KomuraSoft LLC
Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.