Originalmente, não era possível deixar o sistema operacional convidado usar hardware real porque não havia como controlá-lo. Se você tentasse executá-lo na CPU real, não tinha garantia de que ele entregaria o controle de volta ao SO host.
A virtualização, conforme você a descreve, é implementada no hardware, permitindo que certas regras e restrições sejam aplicadas no nível do hardware, que podem ser gerenciadas pelo sistema operacional host. Isso permite que o sistema operacional host configure regras sobre o que o convidado pode ou não fazer e, em seguida, execute o convidado em hardware real. Se o convidado tentar fazer algo com o hardware real que viola as regras (como tentar acessar um dispositivo de disco), o hardware suspenderá o convidado e enviará ao host uma interrupção, o que permitirá que o host forneça uma resposta (como retornando dados de um dispositivo de disco emulado) e reinicie o convidado.
Aqui está um exemplo simplificado do processo:
Sistema operacional host: Ei, CPU, preciso que você execute esse código virtualizado. Ligue-me se quiser fazer algo que não seja apenas executar instruções.
CPU host: Você conseguiu!
A CPU do host salva todos os registros e estados do host e começa a executar o código do SO convidado
SO convidado: Estou vivo! Ei CPU, você pode me pegar esse arquivo?
CPU do host: Uh ... claro. Um momento.
A CPU do host salva todos os registros e estado do convidado e, em seguida, restaura todos os registros e estado do
host CPU do host: Ei Host OS, o hóspede queria esse arquivo!
Sistema operacional host: Bem, dê a eles o seguinte: Arquivo do disco rígido virtual
CPU host: Você conseguiu!
A CPU do host salva todos os registros e estados do host, restaura os registros e o estado do convidado e começa a executar o código do SO convidado
CPU do host: Aqui está esse arquivo!
SO convidado: Doce, obrigado!
A principal diferença aqui está em um emulador, o sistema operacional convidado nunca está realmente em execução no hardware. Com a virtualização, o sistema operacional host configura limitações na CPU e, em seguida, executa o código do convidado na CPU física. O exemplo acima é extremamente simplificado, mas a memória, a E / S do disco e até a rede podem ser controladas nos mais recentes processadores de hoje, permitindo a interface com segurança sem a necessidade de incomodar o sistema operacional do host. Desde que o convidado não tente sair dos limites virtualizados, o SO Host poderá não ter nenhum código em execução se não tiver nada a fazer em um determinado momento.
Para adicionar um pouco de perspectiva, este é apenas mais um passo em uma longa história de virtualização e controle. (Não há garantias de que esteja na ordem correta ou seja exaustiva, mas deve fornecer uma boa visão geral inicial)
Originalmente, não havia virtualização. Todos os processos compartilhavam o mesmo espaço de memória, todos tinham acesso total ao hardware, e a capacidade de realizar várias tarefas dependia inteiramente de um processo parar e dar controle ao próximo processo. Se o sistema operacional quisesse ter algum tipo de controle sobre um processo, ele precisaria executá-lo em um emulador (ninguém o fez, porque era muito dolorosamente lento).
A primeira foi a Memória Privilegiada : certas ações que só podem ser executadas por regiões especiais da memória. Essas regiões são ocupadas pelo sistema operacional, permitindo que ele atue como um gateway para essas ações privilegiadas. Um exemplo é a capacidade de ler / gravar dados no hardware. Isso evita que os processos leiam / gravem diretamente no disco rígido e os obriga a solicitar ao sistema operacional que leia / escreva para eles. Isso significa que o sistema operacional pode verificar se o processo tem permissão antes de executar a ação.
Em seguida, veio o "tempo" virtualizado, por assim dizer. O sistema operacional pode configurar a CPU para interromper o processo ativo em intervalos definidos, permitindo que ele assuma o controle do agendamento e alterne entre processos. O sistema operacional agora podia executar processos diretamente no hardware e ainda impedir que usurpassem o tempo da CPU. Isso foi fornecido por um temporizador de hardware .
A seguir, veio a memória virtualizada : O problema da memória compartilhada é que qualquer processo pode ler a memória de qualquer outro processo. O que acontece quando o programa de Mary lê a senha de Bob em seu navegador? A memória virtual permite que o sistema operacional mapeie a memória que um processo vê para diferentes partes da memória física, ou mesmo remova-as completamente da memória física (para o arquivo de paginação). Sempre que um processo tenta ler ou gravar na memória, a VMMU (unidade de gerenciamento de memória virtual) da CPU procura onde está mapeado na memória física e executa a ação lá. Se estiver sem memória, a CPU chama o sistema operacional para buscar a página na memória a partir do arquivo de paginação.
Tudo bem, então, neste momento, chegamos ao início do processador X86, onde podemos executar processos com segurança e impedir ativamente que eles assumam o sistema, a menos que o SO permita especificamente. Neste ponto, os processos são efetivamente "virtualizados". Esse suporte existe há muito tempo, então você realmente não ouve as pessoas falando sobre processos virtualizados, pois supõe-se que todos os processos estejam virtualizados agora.
Por que os SOs virtualizados são especiais? Por que não podemos simplesmente iniciar um como um processo e deixá-lo fazer suas próprias coisas? Bem, o problema é que, como sistema operacional, o sistema convidado espera poder acessar e usar os mesmos controles que o host usa para controlar processos - basicamente, o sistema operacional espera ser o governante supremo do computador, e simplesmente não ' Não funcionará se não for esse o caso. As extensões de "virtualização de hardware" (AMD-V para AMD e VT-x para Intel) permitem que o host OS forneça um conjunto virtualizado de controles de processos virtuais (memória privilegiada virtual, temporizadores de hardware virtuais, memória virtual virtual).