Добавлен: 29.10.2018
Просмотров: 48209
Скачиваний: 190
7.5. Являются ли гипервизоры настоящими микроядрами?
541
у Linux). Возможно, в будущем API гипервизора или микроядра будет стандартизиро-
вано и последующие операционные системы будут спроектированы для вызова этого
интерфейса вместо использования служебных инструкций. Тогда технология и ис-
пользование виртуальных машин упростятся.
Разница между виртуализацией и паравиртуализацией показана на рис. 7.4. На нем
изображены две виртуальные машины, поддерживаемые VT-оборудованием. На левой
машине в качестве гостевой операционной системы используется немодифицированная
версия Windows. При выполнении служебной инструкции оборудование инициирует
системное прерывание с передачей управления гипервизору, который затем эмулирует
эту инструкцию и возвращает управление. На правой машине используется версия
Linux, модифицированная таким образом, что в ней больше не содержатся служебные
инструкции. Вместо этого, когда у нее возникает потребность во вводе-выводе или
внесении изменений в важные внутренние регистры (например, в регистр, указыва-
ющий на таблицы страниц), она для выполнения данной работы осуществляет вызов
гипервизора точно так же, как прикладная программа совершает системный вызов
в стандартной Linux.
Íåìîäèôèöèðîâàííàÿ
Windows
Ìîäèôèöèðîâàííûé
Linux
Ñèñòåìíîå
ïðåðûâàíèå
èç-çà ñëóæåá-
íîé èíñòðóêöèè
Ñèñòåìíîå
ïðåðûâàíèå
èç-çà âûçîâà
ãèïåðâèçîðà
Ïàðàâèðòóàëèçàöèÿ
Íàñòîÿùàÿ âèðòóàëèçàöèÿ
Ìèêðîÿäðî
Ãèïåðâèçîð ïåðâîãî òèïà
Îáîðóäîâàíèå
Рис. 7.4. Настоящая виртуализация и паравиртуализация
На рис. 7.4 показан гипервизор, разделенный на две части пунктирной линией. На
самом деле на оборудовании выполняется только одна программа. Одна ее часть от-
вечает за интерпретацию перехваченных служебных инструкций, в данном случае
от Windows. А другая часть просто выполняет гипервызовы. На этой части имеется
надпись: «Микроядро». Если гипервизор предназначен для запуска только пара-
виртуализированных гостевых операционных систем, ему не нужно эмулировать
служебные инструкции и мы имеем дело с настоящим микроядром, которое про-
сто предоставляет самые основные службы, такие как диспетчеризация процессов
и управление MMU. Граница между гипервизором первого типа и микроядром уже
стирается и будет становиться все менее различимой по мере того, как гипервизоры
будут приобретать все больше и больше функциональных возможностей и гипер-
вызовов, что представляется вполне возможным развитием событий. Это спорная
тема, но становится все более понятно, что программа, запущенная в режиме ядра
непосредственно на оборудовании, должна быть невелика по размеру и надежна
и состоять не из миллионов, а из тысяч строк кода.
По паравиртуализации гостевой операционной системы возникает ряд вопросов. Во-
первых, если служебные инструкции заменены вызовами гипервизора, то как может
542
Глава 7. Виртуализация и облако
операционная система работать на простом оборудовании? Ведь оборудование не пони-
мает эти гипервызовы. Во-вторых, что, если на рынке имеется несколько гипервизоров,
например VMware, Xen с открытым кодом, изначально созданный в Кембриджском
университете, и Hyper-V компании Microsoft, и у каждого из них имеется в чем-то
отличающийся API-интерфейс гипервизора? Как можно модифицировать ядро для
запуска всех этих гипервизоров?
Решение было предложено в работе Amsden et al. (2006). В их модели ядро, когда
ему нужно выполнить какие-нибудь служебные инструкции, модифицируется для
вызова специальных процедур. Все вместе эти процедуры, названные интерфейсом
виртуальной машины (Virtual Machine Interface (VMI)), образуют низкоуровневый
слой, который взаимодействует с оборудованием или гипервизором. Эти процедуры
разработаны с прицелом на универсальность и не привязаны к какой-либо конкретной
аппаратной платформе или к какому-нибудь конкретному гипервизору.
Экземпляр такой технологии для паравиртуализированной версии Linux, названной
ими VMI Linux (VMIL), показан на рис. 7.5. Когда VMI Linux запускается непо-
средственно на оборудовании, она должна быть подключена к библиотеке, которая,
как показано на рис. 7.5, а, выдает необходимые для работы настоящие (служебные)
инструкции. При работе в режиме гипервизора, например VMware или Xen, гостевая
операционная система подключается к другим библиотекам, совершающим соответ-
ствующие (и уже другие) гипервызовы, направляемые базовому гипервизору. Таким
образом, ядро операционной системы сохраняет переносимость при успешно и эффек-
тивно взаимодействующем с ним гипервизоре.
Îáîðóäîâàíèå
Áèáëèîòåêà
VMIL/HWinterface
Ñëóæåáíàÿ
èíñòðóêöèÿ,
âûïîëíÿåìàÿ
îáîðóäîâàíèåì
VMI Linux
Îáîðóäîâàíèå
VMware
VMI Linux
Áèáëèîòåêà VMIL
äëÿ ðàáîòû ñ Vmware
Âûçîâ ãèïåðâèçîðà
Îáîðóäîâàíèå
Xen
VMI Linux
Áèáëèîòåêà VMIL
äëÿ ðàáîòû ñ Xen
Âûçîâ ãèïåðâèçîðà
à
á
â
Рис. 7.5. VMI Linux, работающая: а — непосредственно на оборудовании;
б — на VMware; в — на Xen
Относительно интерфейса виртуальной машины были внесены и другие предложе-
ния. Одно из популярных предложений называется paravirt ops. Концептуально идея
похожа на то, что уже было описано ранее, но отличается в деталях. По сути, группа
поставщиков Linux, включающая такие компании, как IBM, VMware, Xen и Red Hat,
выступила в поддержку независимого от конкретного гипервизора интерфейса для
Linux. Интерфейс, включенный в основную линейку ядра, начиная с версии 2.6.23,
позволял ядру взаимодействовать с тем гипервизором, который управлял физическим
оборудованием.
7.6. Виртуализация памяти
543
7.6. Виртуализация памяти
До сих пор рассматривался вопрос о том, как виртуализировать центральный процес-
сор. Но в компьютерной системе содержится не только процессор. Имеются также па-
мять и устройства ввода-вывода. Они также должны быть виртуализированы. Давайте
посмотрим, как это делается.
Практически все современные операционные системы поддерживают виртуальную
память, и в основном это выражается в отображении страниц в виртуальном адрес-
ном пространстве на страницы в физической памяти. Это отображение определяется
многоуровневыми таблицами страниц. Обычно отображение приводится в действие
установкой операционной системой управляющего регистра в центральном процессоре,
указывающего на таблицу страниц верхнего уровня. Виртуализация сильно усложняет
управление памятью. Фактически прежде чем все получилось, производителями обо-
рудования были предприняты две попытки.
Предположим, к примеру, что виртуальная машина запущена и установленная на ней
гостевая операционная система решила отобразить свои виртуальные страницы 7, 4
и 3 на физические страницы 10, 11 и 12 соответственно. Она строит таблицы страниц,
в которых содержится это отображение, и загружает аппаратный регистр для указания
на таблицу страниц верхнего уровня. Эта инструкция является служебной. На цен-
тральном процессоре с VT-технологией произойдет системное прерывание. С помощью
динамической трансляции будет выдан вызов процедуры гипервизора. На паравир-
туализированной операционной системе будет сгенерирован гипервызов. Чтобы не
усложнять задачу, давайте предположим, что системное прерывание привело к передаче
управления в гипервизор первого типа, но задача точно та же для всех трех вариантов.
Что теперь делает гипервизор? Одно из решений заключается в фактическом выделе-
нии физических страниц 10, 11 и 12 этой виртуальной машине и настройке текущей
таблицы страниц на отображение виртуальных страниц 7, 4 и 3 виртуальной машины
на их использование. Пока все в порядке.
Теперь предположим, что вторая виртуальная машина запускается, отображает свои
виртуальные страницы 4, 5 и 6 на физические страницы 10, 11 и 12 и загружает регистр
управления указателем на свою таблицу страниц. Гипервизор перехватывает системное
прерывание, но что он должен делать? Он не может использовать это отображение,
потому что физические страницы 10, 11 и 12 уже используются. Он может найти
свободные страницы, скажем, 20, 21 и 22, и воспользоваться ими, но сначала должен
создать новую таблицу страниц, отображающую виртуальные страницы 4, 5 и 6 вирту-
альной машины 2 на страницы 20, 21 и 22. Если будет запущена еще одна виртуальная
машина, которая попытается использовать физические страницы 10, 11 и 12, придется
создавать отображение и для них. В общем, для каждой виртуальной машины гиперви-
зору нужно создавать теневую таблицу страниц (shadow page table), отображающую
виртуальные страницы, используемые виртуальной машиной, на реальные страницы,
предоставляемые гипервизором.
Хуже того, при каждом изменении гостевой операционной системой своих таблиц
страниц гипервизор должен также вносить изменения в теневую таблицу страниц. На-
пример, если гостевая операционная система заново отобразит виртуальную страницу 7
на то, что ей видится как физическая страница 200 (вместо страницы 10), гипервизор
должен знать об этом изменении. Беда в том, что гостевая операционная система может
544
Глава 7. Виртуализация и облако
вносить изменения в свои таблицы страниц просто путем записи в память. Служебные
операции для этого не требуются, следовательно, гипервизор даже не знает об изме-
нениях и, конечно же, не может обновить теневые таблицы страниц, используемые
фактическим оборудованием.
Возможное (но не вполне изящное) решение заключается в том, чтобы гипервизор
отслеживал, в какой странице в памяти гостевой операционной системы содержится
таблица страниц верхнего уровня. Эту информацию он может получить при первой
попытке гостевой операционной системы загрузить аппаратный регистр, указывающий
на эту таблицу, потому что эта инструкция является служебной и вызывает перехва-
тываемое системное прерывание. В этот момент гипервизор может создать теневую
таблицу страниц, а также сделать отметку, что таблица страниц верхнего уровня и те
таблицы страниц, на которые она указывает, предназначены только для чтения. По-
следующие попытки со стороны гостевой операционной системы внести изменения
в любую из этих таблиц вызовут ошибку отсутствия страницы, передав таким образом
управление гипервизору, который может проанализировать поток инструкций, опреде-
ляя, что именно пытается сделать гостевая операционная система, и соответствующим
образом обновить теневые таблицы страниц. Решение не самое хорошее, но в принципе
работоспособное.
Еще одно, также не очень изящное решение заключается в прямо противоположных
действиях. В этом случае гипервизор просто позволяет гостевой операционной системе
добавить новое отображение к ее таблицам страниц, как она того пожелает. Как только
это происходит, в теневых таблицах страниц ничего не меняется. Фактически гиперви-
зор даже ничего не знает об этом. Но как только гостевая операционная система пыта-
ется обратиться к любой из новых страниц, происходит ошибка отсутствия страницы
и управление переходит к гипервизору. Он изучает таблицы страниц гостевой операци-
онной системы с целью выявления отображения, которое ему следует добавить, и если
таковое имеется, добавляет его и заново выполняет инструкцию, на которой произошел
сбой. А что происходит, когда гостевая операционная система удаляет отображение
из своих таблиц страниц? Понятно, что гипервизор не вправе ожидать возникнове-
ния ошибки отсутствия страницы, потому что ее не будет. Удаление отображения из
таблицы страниц случается в виде инструкции INVLPG (которая в действительности
предназначена для аннулирования TLB-записи). Следовательно, гипервизор пере-
хватывает эту инструкцию и удаляет отображение и из теневой таблицы страниц. Это
решение также не самое лучшее, но оно работает.
Обе технологии становятся причиной множества ошибок отсутствия страницы, а такие
ошибки обходятся дорого. Обычно мы различаем «нормальные» ошибки отсутствия
страницы, вызываемые гостевой программой, обращающейся к странице, выгруженной
из оперативной памяти, и ошибки отсутствия страницы, связанные с обеспечением
синхронизации теневых таблиц страниц и таблиц страниц гостевой операционной
системы. Первые называются ошибками отсутствия страницы, вызванными гостевой
операционной системой
(guest-induced page faults), и поскольку они перехватываются
гипервизором, то должны быть снова введены в гостевую операционную систему. А это
все обходится недешево. Последние называются ошибками отсутствия страницы,
вызванными гипервизором
(hypervisor-induced page faults), и обрабатываются путем
обновления теневых таблиц страниц.
Ошибки отсутствия страницы всегда дорого обходятся, но особенно явно это проявля-
ется в виртуализированной среде, поскольку они приводят к так называемым выходам
7.6. Виртуализация памяти
545
из виртуальной машины
(VM exit), то есть к ситуации, в которой управление возвраща-
ется гипервизору. Рассмотрим, что нужно сделать центральному процессору для такого
VM-выхода. Сначала он записывает причину VM-выхода, чтобы гипервизор знал, что
делать. Он также записывает адрес гостевой инструкции, ставшей причиной выхода.
Затем осуществляется переключение контекста, которое включает в себя сохранение
всех регистров. Затем он загружает состояние процессора гипервизора. И только по-
том гипервизор может приступить к обработке ошибки отсутствия страницы, начало
которой было таким дорогостоящим. И когда наконец-то все будет сделано, процессор
должен выполнить все шаги в обратном порядке. Процесс может занять десятки тысяч
или даже более тактов. Неудивительно, что специалисты стараются извернуться так,
чтобы сократить количество выходов.
В паравиртуализированной операционной системе ситуация другая. Здесь эта система
в роли гостя знает, что когда она завершит изменение таблицы страниц какого-нибудь
процесса, ей следовало бы информировать гипервизор. Следовательно, сначала она
полностью изменяет таблицу страниц, а затем осуществляет вызов гипервизора, сооб-
щая ему о новой таблице страниц. Таким образом, вместо ошибки защиты при каждом
обновлении таблицы страниц осуществляется один гипервызов, когда все уже будет
обновлено, что, несомненно, более эффективный способ проделывать дела.
7.6.1. Аппаратная поддержка вложенных таблиц страниц
Высокая стоимость обработки теневых таблиц страниц заставила разработчиков
микросхем добавить аппаратную поддержку для вложенных таблиц страниц. Термин
вложенные таблицы страниц
(nested page tables) использовался компанией AMD.
А Intel называет их расширенными таблицами страниц (Extended Page Tables (EPT)).
Они похожи друг на друга и нацелены на удаление основной части издержек путем
полностью аппаратной дополнительной манипуляции с таблицами страниц, и все это
без каких-либо системных прерываний. Интересно, что первое виртуализационное
расширение в процессорах x86 компании Intel вообще не включало поддержки вир-
туализации памяти. Хотя процессоры с VT-расширениями позволили избавиться от
многих узких мест, связанных с виртуализацией центрального процессора, ковыряние
в таблицах страниц обходилось дороже, чем когда-либо. У AMD и Intel ушло несколько
лет на то, чтобы произвести оборудование для эффективной виртуализации памяти.
Вспомним, что даже без виртуализации операционная система поддерживает ото-
бражение виртуальных страниц на физическую страницу. Оборудование «обходит»
таблицы страниц в поисках физического адреса, соответствующего виртуальному
адресу. Добавление дополнительных виртуальных машин приводит просто к добавле-
нию дополнительного отображения. В качестве примера представим, что нам нужно
преобразовать виртуальный адрес Linux-процесса на гипервизоре первого типа вроде
Xen или VMware ESX-сервера в физический адрес. В добавление к гостевым вирту-
альным адресам
(guest virtual addresses) у нас теперь есть гостевые физические адреса
(guest physical addresses) и, соответственно, основные физические адреса (host physical
addresses), которые иногда называют машинными физическими адресами (machine
physical addresses). Мы видели, что без EPT гипервизор отвечал за поддержку теневых
таблиц страниц явным образом. С использованием EPT гипервизор по-прежнему имеет
дополнительный набор таблиц страниц, но теперь центральный процессор способен
обрабатывать основную часть промежуточных уровней также и в оборудовании. В на-
шем примере сначала оборудование обходит обычные таблицы страниц, чтобы преоб-