Xen 4.17 è già stato rilasciato e queste sono le sue novità

Dopo un anno di sviluppo, il lancio di la nuova versione dell'hypervisor gratuito xen 4.17, versione in cui la formazione degli aggiornamenti per il ramo Xen 4.17 durerà fino al 12 giugno 2024 e il rilascio delle correzioni delle vulnerabilità fino al 12 dicembre 2025.

Vale la pena ricordare che aziende come Amazon, Arm, Bitdefender, Citrix, EPAM Systems e Xilinx (AMD) hanno contribuito allo sviluppo della nuova versione.

Nuove funzionalità principali di Xen 4.17

In questa nuova versione che viene presentata, si evidenzia che il possibilità di definire una configurazione Xen statica per i sistemi ARM che codifica in anticipo tutte le risorse necessarie per avviare i sistemi guest. tutte le risorsecome la memoria condivisa, i canali di notifica degli eventi e lo spazio dell'heap dell'hypervisor, sono preallocati all'avvio dell'hypervisor invece di essere assegnati in modo dinamico, il che elimina la possibilità di fallimento dovuto alla mancanza di risorse.

Per sistemi embedded basati su architettura ARM, è stato implementato supporto sperimentale (anteprima tecnica) Per la virtualizzazione I/O che utilizza i protocolli VirtIO, virtio-mmio viene utilizzato per comunicare con il dispositivo I/O virtuale, che ci ha permesso di garantire la compatibilità con un'ampia gamma di dispositivi VirtIO. Troviamo anche la compatibilità implementata per il frontend Linux, con libxl/xl, la modalità dom0less e i backend userspace.

Un altro dei cambiamenti che spicca è il is supporto migliorato per la modalità dom0less, che permette di evitare di implementare un ambiente dom0 quando si avviano le macchine virtuali in una fase iniziale dell'avvio del server.

Il possibilità di definire gruppi di CPU (CPUPOOL) in fase di avvio (tramite l'albero dei dispositivi), which permette di utilizzare gruppi in configurazioni senza dom0, ad esempio, per collegare diversi tipi di core della CPU nei sistemi ARM basati sull'architettura big.LITTLE, che combina core potenti, ma assetati di energia, e core meno produttivi, ma più efficienti dal punto di vista energetico. Inoltre, dom0less offre la possibilità di associare il frontend/backend di paravirtualizzazione ai guest, consentendo di avviare i guest con i necessari dispositivi paravirtualizzati.

Nei sistemi ARM, strutture di virtualizzazione della memoria (P2M, da fisico a macchina) ora vengono assegnati dal pool di memoria creato quando viene creato un dominio, consentendo un migliore isolamento tra i guest quando si verificano errori relativi alla memoria.

Nei sistemi x86, sono supportate le pagine IOMMU (superpage) per tutti i tipi di sistemi guest, consentendo maggiori prestazioni durante l'inoltro di dispositivi, PCI, plus aggiunto il supporto per host con un massimo di 12 TB di RAM. Nella fase di avvio, viene implementata la possibilità di impostare i parametri cpuid per dom0. I parametri VIRT_SSBD e MSR_SPEC_CTRL vengono proposti per controllare la protezione a livello di hypervisor contro gli attacchi alla CPU sui sistemi guest.

Del altre modifiche che risaltano:

• Aggiunta protezione contro la vulnerabilità Spectre-BHB nelle strutture della microarchitettura del processore per i sistemi ARM.
• Sui sistemi ARM, viene fornita la possibilità di eseguire il sistema operativo Zephyr nell'ambiente root Dom0.
  Viene fornita la possibilità di un assieme hypervisor separato (all'esterno dell'albero).

Separatamente, è in fase di sviluppo il trasporto VirtIO-Grant, che differisce da VirtIO-MMIO per un livello di sicurezza più elevato e la possibilità di eseguire i controller in un dominio isolato separato per i controller.

Invece della mappatura diretta della memoria, VirtIO-Grant utilizza la traduzione degli indirizzi fisici del guest in collegamenti di lease, consentendo l'utilizzo di aree di memoria condivise pre-concordate per lo scambio di dati tra il guest e il backend VirtIO, senza concedere al backend il diritto di eseguire la mappatura della memoria. Il supporto VirtIO-Grant è già implementato nel kernel Linux, ma non è ancora incluso nei backend QEMU, virtio-vhost e toolkit (libxl/xl).

L'iniziativa Hyperlaunch continua a svilupparsi per fornire strumenti flessibili per personalizzare l'avvio di macchine virtuali all'avvio del sistema. Attualmente, il primo set di patch è pronto, rendendo possibile la definizione dei domini PV e il trasferimento delle loro immagini all'hypervisor al momento del caricamento. voi

Infine Se sei interessato a saperne di più, puoi consultare i dettagli nel seguente link.