Первоначально, вы не могли позволить гостевой ОС использовать реальное оборудование, потому что у вас не было возможности управлять им. Если вы пытались запустить его на реальном процессоре, у вас не было никакой гарантии, что он вернет управление обратно в хост-систему.
Виртуализация, как вы ее описали, реализована на аппаратном уровне, позволяя применять определенные правила и ограничения на аппаратном уровне, которым может управлять хост-ОС. Это позволяет операционной системе хоста устанавливать правила о том, что гость может и не может делать, а затем фактически запускать гость на реальном оборудовании. Если гость пытается что-то сделать с реальным оборудованием, которое нарушает правила (например, пытается получить доступ к дисковому устройству), оборудование приостановит гостя и отправит хосту прерывание, которое позволяет хосту предоставить ответ (например, возвращение данных с эмулируемого дискового устройства), а затем возобновить работу гостя.
Вот упрощенный пример процесса:
ОС хоста: Эй, процессор, мне нужно, чтобы вы виртуализировали этот код. Позвоните мне, если он хочет сделать что-то, что не просто выполняет инструкции.
Процессор хоста: Вы получили это!
ЦП хоста сохраняет все регистры и состояние хоста, а затем начинает выполнять код гостевой ОС
Гостевая ОС: я жива! Эй, процессор, ты можешь достать мне этот файл?
Процессор хоста: Э-э ... конечно. Один момент.
ЦП хоста сохраняет все гостевые регистры и состояние, а затем восстанавливает все регистры и состояние хоста.
Процессор хоста: Привет хост ОС, Гость хотел этот файл!
ОС хоста: О, хорошо, дайте им это: Файл с виртуального жесткого диска
Процессор хоста: Вы получили это!
ЦП хоста сохраняет все регистры и состояние хоста, восстанавливает гостевые регистры и состояние, а затем начинает выполнение кода гостевой ОС
Центральный процессор: вот этот файл!
Гостевая ОС: Сладко, спасибо!
Ключевое отличие здесь заключается в эмуляторе, гостевая ОС фактически никогда не работает на оборудовании. При виртуализации хост-ОС настраивает ограничения в ЦП, а затем фактически запускает гостевой код на физическом ЦП. Приведенный выше пример чрезвычайно упрощен, но память, дисковый ввод-вывод и даже работа в сети можно контролировать на самых современных современных процессорах, что позволяет им безопасно взаимодействовать без необходимости каждый раз беспокоить операционную систему хоста. До тех пор, пока гость не пытается выйти за пределы виртуализированных границ, то на хост-ОС может не работать какой-либо код, если в данный момент времени ему нечего делать.
Чтобы добавить немного перспективы, это просто еще один шаг в долгой истории виртуализации и управления. (Нет гарантий, что это в правильном порядке или является исчерпывающим, но должно дать хороший начальный обзор)
Первоначально не было никакой виртуализации. Все процессы совместно используют одно и то же пространство памяти, все имеют полный доступ к аппаратному обеспечению, а возможность многозадачности полностью зависит от остановки одного процесса и передачи управления следующему процессу. Если ОС хотела иметь какой-либо контроль над процессом, она должна была запускать процесс в эмуляторе (никто не делал, потому что он был слишком болезненно медленным).
Сначала была привилегированная память: определенные действия, которые могут быть выполнены только специальными областями памяти. Эти регионы заняты ОС, что позволяет ей выступать в качестве шлюза для этих привилегированных действий. Примером является возможность чтения / записи данных на оборудование. Это предотвращает процессы чтения / записи непосредственно на жесткий диск и вместо этого заставляет их запрашивать у ОС чтение / запись для них. Это означает, что ОС может проверить, есть ли у процесса разрешение перед выполнением действия.
Далее пришло виртуализированное "время" как бы. ОС может настроить ЦП на прерывание активного процесса через заданные интервалы, что позволит ему контролировать планирование и переключаться между процессами. Операционная система теперь может запускать процессы непосредственно на оборудовании и при этом предотвращать неправильное использование процессорного времени. Это было обеспечено аппаратным таймером.
Затем появилась виртуализированная память: проблема с разделяемой памятью заключается в том, что любой процесс может читать память любого другого процесса. Что происходит, когда программа Мэри считывает пароль Боба из своего веб-браузера? Виртуальная память позволяет ОС сопоставлять память, которую видит процесс, с различными частями физической памяти или даже полностью перемещать их из физической памяти (в файл подкачки). Каждый раз, когда процесс пытается читать или записывать в память, VMMU (блок управления виртуальной памятью) ЦП ищет, где он отображается в физической памяти, и выполняет там действие. Если он сопоставлен с памятью, то ЦП вызывает ОС для извлечения страницы в память из файла подкачки.
Итак, на данный момент мы подошли к началу работы процессора X86, где мы можем безопасно запускать процессы и активно предотвращать их захват системы, если только ОС специально не позволяет им это делать. На этом этапе процессы фактически "виртуализированы". Эта поддержка существует уже давно , поэтому вы на самом деле не слышите, чтобы люди говорили о виртуализированных процессах, поскольку предполагается, что все процессы теперь виртуализированы.
Почему виртуализированные ОС особенные? Почему мы не можем просто запустить процесс как процесс и позволить ему делать свое дело? Проблема в том, что в качестве операционной системы гостевая система рассчитывает получить доступ к тем же элементам управления, которые используются хостом для управления процессами, и использовать их - в основном ОС ожидает, что она будет верховным правителем компьютера, а они просто не не работает, если это не так. Расширения "Аппаратная виртуализация" (AMD-V для AMD и VT-x для Intel) позволяют ОС хоста предоставлять виртуализированный набор элементов управления виртуальными процессами (виртуальная привилегированная память, виртуальные аппаратные таймеры, виртуальная виртуальная память).
