{"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\/pt\/blog\/administrirovanie\/obshhie-printsipy-raboty-qemu-kvm","title":{"rendered":"Princ\u00edpios gerais de funcionamento do QEMU-KVM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Princ\u00edpios
\n
\nMinha compreens\u00e3o atual:<\/p>\n

1) KVM<\/h2>\n

\nKVM (Kernel-based Virtual Machine) \u00e9 um hipervisor (VMM - Virtual Machine Manager) que opera como um m\u00f3dulo no sistema operacional Linux. O hipervisor \u00e9 necess\u00e1rio para executar um software em um ambiente que n\u00e3o existe (virtual) e, ao mesmo tempo, esconder o hardware f\u00edsico real em que esse software est\u00e1 funcionando. O hipervisor atua como um 'intermedi\u00e1rio' entre o hardware f\u00edsico (host) e o sistema operacional virtual (convidado).<\/p>\n

Como o KVM \u00e9 um m\u00f3dulo padr\u00e3o do kernel Linux, ele recebe todas as funcionalidades do kernel (gerenciamento de mem\u00f3ria, escalonador etc.). Assim, todos esses benef\u00edcios tamb\u00e9m s\u00e3o repassados aos convidados (j\u00e1 que os convidados operam em um hipervisor que funciona no\/n\u00facleo do sistema operacional Linux).<\/p>\n

O KVM \u00e9 muito r\u00e1pido, mas em si n\u00e3o \u00e9 suficiente para executar um sistema operacional virtual, pois para isso \u00e9 necess\u00e1ria a emula\u00e7\u00e3o de I\/O. Para I\/O (processador, discos, rede, v\u00eddeo, PCI, USB, portas seriais etc.), o KVM utiliza o QEMU.
\n<\/a><\/noindex><\/p>\n

2) QEMU<\/h2>\n

\nQEMU (Quick Emulator) \u00e9 um emulador de v\u00e1rios dispositivos, que permite executar sistemas operacionais destinados a uma arquitetura em outra (por exemplo, ARM -> x86). Al\u00e9m do processador, o QEMU emula v\u00e1rios dispositivos perif\u00e9ricos: placas de rede, HDD, placas de v\u00eddeo, PCI, USB etc.<\/p>\n

Funciona da seguinte maneira:<\/p>\n

Instru\u00e7\u00f5es\/c\u00f3digo bin\u00e1rio (por exemplo, ARM) s\u00e3o convertidas em c\u00f3digo intermedi\u00e1rio independente de plataforma por meio de um conversor TCG (Tiny Code Generator) e, em seguida, esse c\u00f3digo bin\u00e1rio independente de plataforma \u00e9 convertido em instru\u00e7\u00f5es\/c\u00f3digo de destino (por exemplo, x86).<\/p>\n

ARM -> c\u00f3digo_intermedi\u00e1rio -> x86<\/p>\n

Na verdade, voc\u00ea pode executar m\u00e1quinas virtuais no QEMU em qualquer host, mesmo em modelos antigos de processadores que n\u00e3o suportam Intel VT-x (Intel Virtualization Technology) \/ AMD SVM (AMD Secure Virtual Machine). No entanto, assim, o desempenho ser\u00e1 bastante lento, devido ao fato de o c\u00f3digo bin\u00e1rio execut\u00e1vel precisar ser recompilado em tempo real duas vezes, usando o TCG (TCG \u00e9 um compilador Just-in-Time).<\/p>\n

Ou seja, o QEMU por si s\u00f3 \u00e9 incr\u00edvel, mas funciona muito lentamente.<\/p>\n

3) An\u00e9is de prote\u00e7\u00e3o<\/h2>\n

\n\"Princ\u00edpios
\n
\nO c\u00f3digo de programa bin\u00e1rio nos processadores n\u00e3o opera de forma aleat\u00f3ria, mas est\u00e1 disposto em diferentes n\u00edveis (an\u00e9is \/ Protection rings) com diferentes n\u00edveis de acesso aos dados, desde o mais privilegiado (Anel 0) at\u00e9 o mais restritivo, regulado e 'apertado' (Anel 3).<\/p>\n

O sistema operacional (n\u00facleo do SO) opera em Ring 0 (modo kernel) e pode fazer o que quiser com quaisquer dados e dispositivos. Aplicativos de usu\u00e1rio funcionam em Ring 3 (modo usu\u00e1rio) e n\u00e3o t\u00eam o direito de fazer o que desejarem, devendo, em vez disso, solicitar acesso para realizar determinada opera\u00e7\u00e3o (dessa forma, os aplicativos de usu\u00e1rio t\u00eam acesso apenas aos seus pr\u00f3prios dados e n\u00e3o podem \"invadir\" a \"caixa de areia\" de outrem). Rings 1 e 2 s\u00e3o destinados ao uso por drivers.<\/p>\n

Antes da inven\u00e7\u00e3o do Intel VT-x \/ AMD SVM, hipervisores operavam em Ring 0 e os convidados em Ring 1. Como Ring 1 n\u00e3o tem privil\u00e9gios suficientes para o funcionamento normal do SO, a cada chamada privilegiada do sistema convidado, o hipervisor precisava modificar essa chamada em tempo real e execut\u00e1-la em Ring 0 (de forma semelhante ao que faz o QEMU). Ou seja, o c\u00f3digo bin\u00e1rio convidado N\u00c3O<\/i><\/b> era executado diretamente no processador, mas passava por v\u00e1rias modifica\u00e7\u00f5es intermedi\u00e1rias em tempo real a cada vez.<\/p>\n

As sobrecargas eram consider\u00e1veis e isso representava um grande problema, e ent\u00e3o os fabricantes de processadores, independentemente, lan\u00e7aram um conjunto avan\u00e7ado de instru\u00e7\u00f5es (Intel VT-x \/ AMD SVM), permitindo a execu\u00e7\u00e3o de c\u00f3digo dos sistemas operacionais convidados DIRECTAMENTE<\/i><\/b> no processador host (pulando todas as etapas intermedi\u00e1rias custosas, como era feito anteriormente).<\/p>\n

Com a chegada do Intel VT-x \/ AMD SVM, um novo n\u00edvel especial Ring -1 (menos um) foi criado. E agora, neste n\u00edvel, opera o hipervisor, enquanto os convidados funcionam em Ring 0 e recebem acesso privilegiado ao CPU.<\/p>\n

Ou seja, no final das contas:<\/p>\n