Виртуализация х86-й архитектуры

VMM запускает текущую виртуальную машину, позволяя ей двигаться дальше. VMM, который создан для виртуализированной архитектуры, использует технологию, известную как перехват и эмуляция, для непосредственного выполнения последовательности инструкций виртуальной машины, но безопасным образом, на оборудовании.
При невозможности подобных действий одним из подходов было указание виртуализируемого поднабора процессорной архитектуры и портирование гостевой операционной системы на эту заново определенную платформу. Эта технология называется паравиртуализацией (Barham et al., 2003; Whitaker et al., 2002) и требует модификации операционной системы на уровне исходного кода. Точнее говоря, при паравиртуализации гостевая операционная система модифицируется во избежание выполнения тех действий, которые не могут быть обработаны гипервизором. В VMware паравиртуализация была невозможна из-за требований обеспечения совместимости и необходимости запуска операционных систем, чей исходный код был недоступен, в частности Windows.

Нужно было воспользоваться альтернативным подходом и провести полную эмуляцию. При этом инструкции виртуальных машин вместо непосредственного выполнения на оборудовании эмулировались VMM. При этом можно было добиться достаточной эффективности. Предыдущий опыт с машинным симулятором SimOS (Rosenblum et al., 1997) показал, что использование таких технологий, как динамическая двоичная трансляция, запущенных в виде программы, выполняемой в пользовательском режиме, может ограничить издержки от полной эмуляции пятикратным замедлением. При всей своей эффективности и несомненной пригодности в целях моделирования пятикратное замедление было абсолютно неприемлемым и не могло соответствовать желаемым требованиям производительности.

Решение данной проблемы было в сочетании двух основных идей. Во-первых, хотя для виртуализации всей архитектуры x86 технология непосредственного выполнения инструкций после их перехвата и эмуляции не всегда подходила, в отдельные моменты ее можно было применить. В частности, она могла использоваться в ходе выполнения тех прикладных программ, на долю которых приходится большая часть времени при соответствующих рабочих нагрузках. Дело в том, что инструкции, чувствительные к виртуализации, являются таковыми не всегда, а только при определенных обстоятельствах. Например, инструкция POPF чувствительна к виртуализации, когда от программного обеспечения ожидается возможность блокировки прерываний (например, при запуске операционной системы), но она нечувствительна к виртуализации, когда программное обеспечение не может заблокировать прерывания (что случается при выполнении почти всех приложений на уровне пользователя).

На рис. 7.7 показаны модульные строительные блоки исходного монитора VMware VMM. Видно, что он состоит из подсистемы непосредственного выполнения, подсистемы двоичной трансляции и алгоритма решения, определяющего, какая из подсистем должна использоваться. Обе подсистемы зависят от ряда совместно используемых модулей, например для виртуализации памяти посредством теневых таблиц страниц или эмулирования устройств ввода-вывода.

Рис. 7.7. Высокоуровневые компоненты монитора виртуальных машин VMware (за исключением аппаратной поддержки)


Предпочтительнее, конечно, использование подсистемы непосредственного выполнения, а подсистема динамической двоичной трансляции предоставляет резервный механизм, когда непосредственное выполнение невозможно. Такой случай представляется, к примеру, когда виртуальная машина находится в таком состоянии, при котором она может выдать чувствительную к виртуализации (служебную) инструкцию. Таким образом, каждая подсистема постоянно переоценивает алгоритм решения, чтобы определить возможность переключения подсистем (с двоичной трансляции на непосредственное выполнение) или необходимость такого переключения (с непосредственного выполнения на двоичную трансляцию). Этот алгоритм имеет ряд входных параметров, таких как текущее кольцо выполнения виртуальной машины, возможность включения прерываний на этом уровне и состояние сегментов.

Например, двоичная трансляция должна использоваться при возникновении следующих обстоятельств:

♦ виртуальная машина в данный момент запущена в режиме ядра (кольцо 0 в архитектуре x86);

♦ виртуальная машина может заблокировать прерывания и выдать инструкции ввода-вывода (в архитектуре x86, когда уровень привилегий ввода-вывода установлен на уровне кольца);

♦ виртуальная машина в данный момент запущена в реальном режиме, кроме всего прочего, для BЮS используется устаревший 16-разрядный режим выполнения.

Фактический алгоритм решения содержит несколько дополнительных условий. Подробности можно найти в работе Bugnion et al. (2012). Интересно, что алгоритм не зависит от инструкций, которые сохранены в памяти и могут быть выполнены, он зависит только от значения нескольких виртуальных регистров, таким образом, он весьма эффективно может быть вычислен всего лишь за несколько инструкций.

Второй ключ к пониманию заключался в том, что при надлежащей конфигурации оборудования, особенно при осмотрительном использовании имеющегося в х86 механизма защиты сегментов, системный код при динамической двоичной трансляции также может выполняться на близких к исходным скоростях. Это сильно отличается от пятикратного замедления, обычно ожидаемого от машинных симуляторов.

Разницу можно объяснить путем сравнения того, как динамическая двоичная трансляция преобразует простую инструкцию обращения к памяти. Чтобы эмулировать эту инструкцию в программе, классическому двоичному транслятору, эмулирующему полный набор инструкций архитектуры х86, придется сначала проверить, попадает ли эффективный адрес в диапазон сегмента данных, затем преобразовать адрес в физический адрес и, наконец, скопировать слово, на которое была ссылка, в симулируемый регистр. Разумеется, все эти действия могут быть оптимизированы путем кэширования способом, весьма похожим на тот, которым процессор кэширует отображение в таблицах страниц в буфере ассоциативной трансляции. Но даже такая оптимизация приведет к расширению отдельных инструкций в последовательность инструкций.

Двоичный транслятор в программах подобных действий не совершает. Вместо этого он конфигурирует оборудование таким образом, чтобы эти простые инструкции могли быть заново выданы в виде идентичных инструкций. Это возможно только потому, что УМ'дааге УМЫ (компонентом которого является двоичный транслятор) имеет заранее настроенное под конкретную спецификацию виртуальной машины оборудование:

♦ УММ использует теневые таблицы страниц, гарантирующие, что блок управления памятью может использоваться напрямую (а не эмулироваться);

♦ УММ использует такой же подход с теневыми таблицами для таблиц дескрипторов сегментов (играющих большую роль в 16- и 32-разрядном программном обеспечении на более старых операционных системах для х86).

Разумеется, без сложностей и тонкостей не обошлось. Одним из важных аспектов конструкции является обеспечение целостности в песочнице виртуализации, то есть обеспечение того, что никакая программа, запущенная внутри виртуальной машины (включая и вредоносную программу), не сможет вмешиваться в работу УММ. Эта проблема обычно называется изоляцией сбоя программы и, если решение реализовано в программе, добавляет к каждому обращению к памяти издержки времени выполнения. Здесь также УМ'дааге УММ использует другой, основанный на оборудовании подход. Он разбивает адресное пространство на две разделенные зоны. Верхние 4 Мбайт адресного пространства УММ резервирует под собственные нужды. Тем самым для использования виртуальной машиной освобождается все остальное пространство (то есть 4 Гбайт - 4 Мбайт, если речь идет о 32-разрядной архитектуре). Затем УММ конфигурирует аппаратную часть, занимающуюся сегментацией, таким образом, чтобы никакие инструкции виртуальной машины (включая и те, что сгенерированы двоичным транслятором) никогда не получали доступ к верхней 4-мегабайтной области адресного пространства.

<< | >>
Источник: Э. ТАНЕНБАУМ Х. БОС. СОВРЕМЕННЫЕ ОПЕРАЦИОННЫЕ СИСТЕМ Ы 4-е ИЗДАНИЕ. 2015

Еще по теме Виртуализация х86-й архитектуры:

  1. Таненбаум Э.. Архитектура компьютера. 5-е изд, 2007
  2. Степанов А. Н.. Архитектура вычислительных систем и компьютерных сетей, 2007
  3. Архитектура
  4. Молитва о возрождении на Земле Священной Архитектуры
  5. Откровение Мастеров. Архитектура – наука о Времени
  6. 5.2.17. Укрепления благосостояния своих лучших сотрудников для увеличения функциональности всех элементов, составляющих структуру и архитектуру цели
  7. Аверьянов Г.П., Дмитриева В.В.. СОВРЕМЕННАЯ ИНФОРМАТИКА, 2011
  8. Григорьев Ю.А., Ревунков Г.И.. Банки данных, 2002
  9. Э. ТАНЕНБАУМ Х. БОС. СОВРЕМЕННЫЕ ОПЕРАЦИОННЫЕ СИСТЕМ Ы 4-е ИЗДАНИЕ, 2015
  10. Конъюнкция Сатурна
  11. Меридиан в деканатах знака Тельца
  12. Конъюнкция или благоприятная конфигурация Парс Фортуны