{"id":37939,"date":"2019-10-31T22:20:41","date_gmt":"2019-10-31T19:20:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/obshhie-printsipy-raboty-qemu-kvm\/"},"modified":"2019-10-31T22:20:41","modified_gmt":"2019-10-31T19:20:41","slug":"obshhie-printsipy-raboty-qemu-kvm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/obshhie-printsipy-raboty-qemu-kvm","title":{"rendered":"Principi generali del funzionamento di QEMU-KVM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Principi
\n
\nLa mia attuale comprensione:<\/p>\n

1) KVM<\/h2>\n

\nKVM (Kernel-based Virtual Machine) \u2013 \u00e8 un hypervisor (VMM \u2013 Virtual Machine Manager) che funziona come modulo su un sistema operativo Linux. L'hypervisor \u00e8 necessario per eseguire del software in un ambiente virtuale (non esistente) e per nascondere all'applicazione il reale hardware fisico su cui opera. L'hypervisor funge da \u00abinterfaccia\u00bb tra l'hardware fisico (host) e il sistema operativo virtuale (guest).<\/p>\n

Poich\u00e9 KVM \u00e8 un modulo standard del kernel Linux, riceve dal kernel tutti i vantaggi necessari (gestione della memoria, scheduler, ecc.). Di conseguenza, tutti questi vantaggi vengono trasferiti anche ai guest (dato che i guest operano su un hypervisor che opera all'interno del kernel del sistema operativo Linux).<\/p>\n

KVM \u00e8 molto veloce, ma da solo non \u00e8 sufficiente per avviare un sistema operativo virtuale, poich\u00e9 richiede l'emulazione dell'I\/O. Per l'I\/O (processori, dischi, rete, video, PCI, USB, porte seriali, ecc.) KVM utilizza QEMU.
\n<\/a><\/noindex><\/p>\n

2) QEMU<\/h2>\n

\nQEMU (Quick Emulator) \u2013 \u00e8 un emulatore di vari dispositivi che consente di eseguire sistemi operativi progettati per un'architettura su un'altra (ad esempio, ARM \u2013> x86). Oltre al processore, QEMU emula anche diversi dispositivi periferici: schede di rete, HDD, schede video, PCI, USB, ecc.<\/p>\n

Funziona cos\u00ec:<\/p>\n

Le istruzioni\/codice binario (ad esempio, ARM) vengono convertiti in codice intermedio indipendente dalla piattaforma tramite un convertitore TCG (Tiny Code Generator) e poi questo codice binario intermedio viene convertito in istruzioni\/codice target (ad esempio, x86).<\/p>\n

ARM \u2013> codice_intermedio \u2013> x86<\/p>\n

In sostanza, \u00e8 possibile eseguire macchine virtuali su QEMU su qualsiasi host, anche con modelli di processori pi\u00f9 vecchi che non supportano Intel VT-x (Intel Virtualization Technology) \/ AMD SVM (AMD Secure Virtual Machine). Tuttavia, in tal caso, le prestazioni saranno piuttosto lente, poich\u00e9 il codice binario eseguibile deve essere ricompilato al volo due volte, tramite TCG (TCG \u00e8 un compilatore Just-in-Time).<\/p>\n

Cio\u00e8, QEMU \u00e8 davvero fantastico, ma funziona molto lentamente.<\/p>\n

3) Anelli di protezione<\/h2>\n

\n\"Principi
\n
\nIl codice binario software sui processori non opera cos\u00ec liberamente, ma si colloca a diversi livelli (anelli \/ Protection rings) con diverse autorizzazioni per l'accesso ai dati, dal livello pi\u00f9 privilegiato (Ring 0) a quello pi\u00f9 limitato e regolato (Ring 3).<\/p>\n

Il sistema operativo (nucleo OS) funziona su Ring 0 (modalit\u00e0 kernel) e pu\u00f2 fare qualsiasi cosa con i dati e i dispositivi. Le applicazioni utente operano a livello Ring 3 (modalit\u00e0 utente) e non possono fare tutto ci\u00f2 che vogliono, ma devono invece richiedere l'accesso per eseguire determinate operazioni (in questo modo, le applicazioni utente hanno accesso solo ai propri dati e non possono 'intrufolarsi' nella 'sandbox' altrui). Ring 1 e 2 sono destinati all'uso dei driver.<\/p>\n

Prima dell'invenzione di Intel VT-x \/ AMD SVM, gli hypervisor funzionavano su Ring 0, mentre gli ospiti operavano su Ring 1. Poich\u00e9 Ring 1 non ha abbastanza privilegi per il corretto funzionamento dell'OS, ogni volta che c'era una chiamata privilegiata dal sistema ospite, l'hypervisor doveva modificare al volo questa chiamata ed eseguirla su Ring 0 (in un modo simile a come fa QEMU). Ovvero, il codice binario dell'ospite NO<\/i><\/b> veniva eseguito direttamente sulla CPU, ma ogni volta passava attraverso diverse modifiche intermedie al volo.<\/p>\n

Le spese generali erano significative e questo era un grande problema e cos\u00ec i produttori di processori, indipendentemente l'uno dall'altro, rilasciarono un set di istruzioni esteso (Intel VT-x \/ AMD SVM), che consentiva di eseguire il codice dei sistemi operativi ospiti DIRECTAMENTE<\/i><\/b> sulla CPU host (saltando qualsiasi fase intermedia costosa, come avveniva in precedenza).<\/p>\n

Con l'emergere di Intel VT-x \/ AMD SVM, \u00e8 stato creato un nuovo livello speciale Ring -1 (meno uno). E ora su di esso funziona l'hypervisor, mentre gli ospiti operano su Ring 0 e ottengono accesso privilegiato alla CPU.<\/p>\n

Quindi, in sintesi:<\/p>\n