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