Виртуализация оборудования, не готового к виртуализации

Создание виртуальной машины при доступности VT-технологии особых вопросов не вызывает, но что делали люди до ее появления? Например, компания VMware реализовала гипервизор задолго до появления виртуализационных расширений на x86.
И опять ответ заключается в том, что разработчики программного обеспечения, создавшие такие системы, очень разумно распорядились двоичной трансляцией (binary translation) и свойствами оборудования, имевшегося на x86, такого как кольца защиты (protection rings) процессора.

Многие годы в x86 поддерживались четыре режима, или кольца, защиты. Кольцо 3 наименее привилегированное. В нем выполняются обычные пользовательские процессы. В этом кольце невозможно выполнить привилегированные инструкции. Кольцо 0 наиболее привилегированное, позволяющее выполнять любую инструкцию. В нормальных условиях ядро работает в кольце 0. Остальные два кольца ни одной текущей операционной системой не используются. Иными словами, гипервизоры могли свободно использовать их по своему усмотрению. Как показано на рис. 7.3, вследствие этого многие решения по виртуализации содержали гипервизор в режиме ядра (кольцо 0), приложения — в пользовательском режиме (кольцо 3), а гостевую операционную систему помещали на уровень с промежуточной привилегией (кольцо 1). В результате ядро имело более высокую привилегированность по отношению к пользовательским процессам, и любая попытка доступа к памяти ядра из пользовательской программы приводила к нарушению прав доступа. В то же время привилегированные инструкции гостевой операционной системы вызывали системное прерывание с передачей управления гипервизору. Гипервизор проводил ряд проверок корректности, а затем выполнял инструкции от имени гостевой операционной системы.

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

Рис. 7.3. Двоичный транслятор переписывает инструкции гостевой операционный системы, работающей в кольце 1, в то время как гипервизор работает в кольце 0


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

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

В то же время двоичная трансляция довольно часто применяется ко всему коду гостевой операционной системы, выполняемой в кольце 1, и при этом даже заменяются привилегированные служебные инструкции, что в принципе может быть сделано также при обработке служебного прерывания.

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

Все сказанное до сих пор относилось к гипервизорам первого типа. Хотя концептуально гипервизоры второго типа отличаются от гипервизоров первого типа, в целом в них используются те же самые технологии. Например, VMware ESX Server (гипервизор, впервые поставленный в 2001 году) использует в точности такую же двоичную трансляцию, как и первая версия VMware Workstation (гипервизор второго типа, выпущенный двумя годами ранее).

Но запуск кода гостевой операционной системы обычным порядком и использование в точности таких же технологий требуют от гипервизора второго типа искусного управления оборудованием на самом низком уровне, что невозможно сделать из пользовательского пространства. Например, нужно установить дескрипторы сегментов в точности на правильное значение для гостевого кода. Для точной виртуализации гостевая операционная система должна быть введена в заблуждение и полагать, что она воистину царь горы и имеет полный контроль над всеми ресурсами машины, а также доступ ко всему адресному пространству (4 Гбайт на 32-разрядной машине). Когда царь обнаружит присутствие другого царя (ядра основной операционной системы), незаконно вселившегося в его адресное пространство, он не будет удивлен.

К сожалению, именно так и происходит, когда гостевая операционная система запускается в качестве пользовательского процесса на обычной операционной системе. Например, в Linux пользовательский процесс имеет доступ лишь к 3 Гбайт из 4-гигабайтного адресного пространства, поскольку оставшийся 1 Гбайт зарезервирован под ядро. Любое обращение к памяти ядра приводит к системному прерыванию. В принципе, есть возможность перехватить системное прерывание и эмулировать соответствующие действия, но это обходится слишком дорого и обычно требует установки соответствующего обработчика системного прерывания в ядро основной операционной системы. Другой (общеизвестный) способ решения проблемы двух царей заключается в переконфигурации системы для удаления основной операционной системы и фактическом предоставлении гостевой операционной системе всего адресного пространства. Но сделать это из пользовательского пространства в принципе невозможно.

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

Поэтому у большинства современных гипервизоров второго типа имеется модуль ядра, действующий в кольце 0, который позволяет им искусно управлять оборудованием при выполнении привилегированных инструкций. Конечно, в управлении оборудованием на самом низком уровне и предоставлении гостевой операционной системе доступа ко всему адресному пространству нет ничего плохого, но рано или поздно гипервизору понадобится его очистить и восстановить исходный контекст процессора. Допустим, к примеру, что во время работы гостевой операционной системы поступило прерывание от внешнего устройства. Поскольку гипервизор второго типа зависит от драйверов устройств основной операционной системы, для запуска кода гостевой операционной системы ему требуется полная переконфигурация оборудования. При запуске драйвера устройства он находит все им ожидаемое. Гипервизор ведет себя как тинейджеры, устраивающие вечеринку, пока родителей нет дома. И нет ничего страшного в полной перестановке мебели при условии, что к возвращению родителей все будет возвращено на прежние места. Переход от конфигурации оборудования для ядра основной операционной системы к конфигурации для гостевой операционной системы известен как переключатель мира (world switch). Более подробно он будет рассмотрен при изучении VMware в разделе 7.12.

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

7.4.2.

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

Еще по теме Виртуализация оборудования, не готового к виртуализации:

  1. Сценарное оборудование
  2. 3. Права и обязанности по поводу предоставления материалов и оборудования, необходимых для работы.
  3. Богомазова Г.Н.. Установка и обслуживание программного обеспечения персональных компьютеров, серверов, периферийных устройств и оборудования, 2015
  4. Готов!
  5. Статья 203-1. Незаконный оборот дисков для лазерных систем считывания, матриц, оборудования и сырья для их производства
  6. Как готовить Мастеров
  7. Готовить будущее молодежи
  8. Глава 11 Будьте готовы к экстренным ситуациям
  9. Тем, кто готовится к ответственной ситуации...
  10. Кто преступление готовил и зачем
  11. Статья 200. Незаконные действия с документами на перевод, платежными карточками и иными средствами доступа к банковским счетам, оборудованием для их изготовления
  12. Как готовиться к судьбоносным событиям и ответственным ситуациям
  13. Статья 188. Похищение путем демонтажа и иным способом электрических сетей, кабельных линий связи и их оборудования - Статья 188 исключена на основании Закона N 270-VI от 15.04.2008
  14. Для того, чтобы освободиться от прошлого, мы должны быть готовы простить
  15. Мы отказываемся от действий или откладываем их из-за того, что считаем себя не готовыми к ним.
  16. 5. Педагог должен быть психологически и профессионально готов к участию в совершенствовании системы образования
  17. Бели мы не готовы в должное время сделать шаг вперед, то нам хочется отступить назад.
  18. Будьте готовы к тому, что после закрытого вопроса ваш собеседник может произнести заранее подготовленную речь.
  19. Когда венерианка готова, марсианин тут как тут