{"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 di 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) \u00e8 un hypervisor (VMM \u2013 Virtual Machine Manager) che funziona come modulo su un sistema operativo Linux. L\u2019hypervisor \u00e8 necessario per eseguire software in un ambiente virtuale non esistente, nascondendo allo stesso tempo l'hardware fisico reale su cui si esegue il software. L'hypervisor funge da \"intermediario\" 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 tutte le funzionalit\u00e0 necessarie (gestione della memoria, pianificatore, ecc.). Di conseguenza, tutti questi vantaggi si trasferiscono anche ai guest (poich\u00e9 i guest lavorano su un hypervisor che opera nel\/nel kernel del sistema operativo Linux).<\/p>\n

KVM \u00e8 molto veloce, ma di per s\u00e9 non \u00e8 sufficiente per avviare un sistema operativo virtuale, poich\u00e9 \u00e8 necessaria anche l'emulazione delle I\/O. Per l'I\/O (processore, dischi, rete, video, PCI, USB, porte seriali, ecc.) KVM utilizza QEMU.
\n<\/a><\/noindex><\/p>\n

2) QEMU<\/h2>\n

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

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

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

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

In sostanza, puoi eseguire macchine virtuali su QEMU su qualsiasi host, anche su vecchi modelli di processori che non supportano Intel VT-x (Intel Virtualization Technology) \/ AMD SVM (AMD Secure Virtual Machine). Tuttavia, in tal caso, funzioner\u00e0 molto lentamente, 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 di per s\u00e9 \u00e8 eccezionale, ma funziona molto lentamente.<\/p>\n

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

\n\"Principi
\n
\nIl codice binario sui processori non opera a caso, ma si dispone a vari livelli (anelli \/ Protection rings) con diversi livelli di accesso ai dati, dal pi\u00f9 privilegiato (Ring 0) al pi\u00f9 ristretto, regolato e \u00abcon le viti serrate\u00bb (Ring 3).<\/p>\n

Il sistema operativo (nucleo OS) opera su Ring 0 (modalit\u00e0 kernel) e pu\u00f2 fare ci\u00f2 che desidera con qualsiasi dato e dispositivo. Le applicazioni utente operano a livello Ring 3 (modalit\u00e0 utente) e non hanno il diritto di fare tutto ci\u00f2 che vogliono, ma devono ogni volta richiedere l'accesso per effettuare determinate operazioni (in questo modo, le applicazioni utente hanno accesso solo ai propri dati e non possono \u00abinfilarsi\u00bb nella \u00absabbiere\u00bb degli altri). Ring 1 e 2 sono destinati all'uso da parte dei driver.<\/p>\n

Prima dell'invenzione di Intel VT-x \/ AMD SVM, gli ipervisor operavano su Ring 0, mentre le macchine virtuali su Ring 1. Poich\u00e9 Ring 1 non aveva abbastanza privilegi per il corretto funzionamento del sistema operativo, ad ogni chiamata privilegiata dal sistema ospite, l'ipervisor doveva modificare on-the-fly questa chiamata ed eseguirla su Ring 0 (circa come fa QEMU). In altre parole, il codice binario dell'ospite NO<\/i><\/b> non veniva eseguito direttamente sul processore, ma ogni volta subiva diverse modifiche intermedie.<\/p>\n

Le spese generali erano significative e ci\u00f2 rappresentava un grande problema; cos\u00ec i produttori di processori, in modo indipendente, hanno rilasciato un set di istruzioni esteso (Intel VT-x \/ AMD SVM) che consente di eseguire codice dei sistemi operativi ospiti DIRECTAMENTE<\/i><\/b> sul processore host (saltando tutte le costose fasi intermedie, come avveniva in passato).<\/p>\n

Con l'arrivo di Intel VT-x \/ AMD SVM, \u00e8 stato creato un nuovo livello speciale Ring -1 (meno uno). Ora su di esso opera l'ipervisor e gli ospiti operano su Ring 0, ottenendo accesso privilegiato alla CPU.<\/p>\n

Cio\u00e8, alla fine:<\/p>\n