Аппаратная виртуализация что это

Технологии аппаратной виртуализации

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

До недавнего времени усилия в области виртуализации операционных систем были сосредоточены в основном в области программных разработок. В 1998 году компания VMware впервые серьезно обозначила перспективы развития виртуальных систем, запатентовав программные техники виртуализации. Благодаря усилиям VMware, а также других производителей виртуальных платформ, и возрастающим темпам совершенствования компьютерной техники, корпоративные и домашние пользователи увидели преимущества и перспективы новой технологии, а рынок средств виртуализации начал расти стремительными темпами. Безусловно, такие крупные компании, как Intel и AMD, контролирующие большую часть рынка процессоров, не могли оставить эту перспективную технологию без внимания. Компания Intel первая увидела в новой технологии источник получения технологического превосходства над конкурентами и начала работу над усовершенствованием x86 архитектуры процессоров в целях поддержки платформ виртуализации. Вслед за Intel компания AMD также присоединилась к разработкам в отношении поддержки аппаратной виртуализации в процессорах, чтобы не потерять позиции на рынке. В данный момент обе компании предлагают модели процессоров, обладающих расширенным набором инструкций и позволяющих напрямую использовать ресурсы аппаратуры в виртуальных машинах.

Развитие аппаратных техник виртуализации

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

Преимущества аппаратной виртуализации над программной

Как работает аппаратная виртуализация

Необходимость поддержки аппаратной виртуализации заставила производителей процессоров несколько изменить их архитектуру за счет введения дополнительных инструкций для предоставления прямого доступа к ресурсам процессора из гостевых систем. Этот набор дополнительных инструкций носит название Virtual Machine Extensions (VMX). VMX предоставляет следующие инструкции: VMPTRLD, VMPTRST, VMCLEAR, VMREAD, VMREAD, VMWRITE, VMCALL, VMLAUNCH, VMRESUME, VMXON и VMXOFF.

Процессор с поддержкой виртуализации может работать в двух режимах root operation и non-root operation. В режиме root operation работает специальное программное обеспечение, являющееся «легковесной» прослойкой между гостевыми операционными системами и оборудованием — монитор виртуальных машин (Virtual Machine Monitor, VMM), носящий также название гипервизор (hypervisor). Слово «гипервизор» появилось интересным образом: когда-то очень давно, операционная система носила название «supervisor», а программное обеспечение, находящееся «под супервизором», получило название «гипервизор».

Чтобы перевести процессор в режим виртуализации, платформа виртуализации должна вызвать инструкцию VMXON и передать управление гипервизору, который запускает виртуальную гостевую систему инструкцией VMLAUNCH и VMRESUME (точки входа в виртуальную машину). Virtual Machine Monitor может выйти из режима виртуализации процессора, вызвав инструкцию VMXOFF.

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

Отличие аппаратной виртуализации от программной

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

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

Недостатки аппаратной виртуализации

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

Наглядно эта процедура выглядит так:

Однако, не стоит преувеличивать опасность. Разработать вредоносную программу, использующую технологии виртуализации все равно гораздо сложнее, нежели, пользуясь «традиционными» средствами, эксплуатирующими различные уязвимости в операционных системах. При этом главное допущение, которое делается теми, кто утверждает, что такое вредоносное ПО сложнее в обнаружении и более того, может не использовать «дырки» в ОС, действуя исключительно «в рамках правил», состоит в том, что якобы виртуализованная операционная система не в состоянии обнаружить, что она запущена на виртуальной машине, что есть исходно неверная посылка. Соответственно, антивирусное обеспечение имеет все возможности обнаружить факт заражения. А, следовательно, пропадает и смысл разрабатывать столь ресурсоемкий и сложный троян, учитывая наличие куда более простых способов вторжения.

Технологии виртуализации компаний Intel и AMD

Компании Intel и AMD, являясь ведущими производителями процессоров для серверных и настольных платформ, разработали техники аппаратной виртуализации для их использования в платформах виртуализации. Эти техники не обладают прямой совместимостью, но выполняют в основном схожие функции. Обе они предполагают наличие гипервизора, управляющего не модифицированными гостевыми системами, и имеют возможности для разработки платформ виртуализации без необходимости эмуляции аппаратуры. В процессорах обеих компаний, поддерживающих виртуализацию, введены дополнительные инструкции для их вызова гипервизором в целях управления виртуальными системами. В данный момент группа, занимающаяся исследованием возможностей аппаратных техник виртуализации, включает в себя компании AMD, Intel, Dell, Fujitsu Siemens, Hewlett-Packard, IBM, Sun Microsystems и VMware.

Виртуализация Intel

Компания Intel официально объявила о запуске технологии виртуализации в начале 2005 года на конференции Intel Developer Forum Spring 2005. Новая технология получила кодовое название Vanderpool и официальное Intel Virtualization Technology (сокращенно Intel VT). Технология Intel VT содержит в себе некоторое множество техник различного класса, имеющих номера версий VT-x, где x — литер, указывающий на подвид аппаратной техники. Была заявлена поддержка новой технологии в процессорах Pentium 4, Pentium D, Xeon, Core Duo и Core 2 Duo. Intel также опубликовала спецификации на Intel VT для Itanium-based процессоров, где технология виртуализации фигурировала под кодовым именем «Silvervale» и версией VT-i. Однако, начиная с 2005 года, новые модели процессоров Itanium не поддерживают x86 инструкции аппаратно, и x86-виртуализация может быть использована на архитектуре IA-64 только с помощью эмуляции.

Для включения технологии Intel VT в компьютерные системы, компания Intel сотрудничала с производителями материнских плат, BIOS и периферийного оборудования, чтобы обеспечить совместимость Intel VT с существующими системами. Во многих компьютерных системах технология аппаратной виртуализации может быть выключена в BIOS. Спецификации на Intel VT говорят, что для поддержки этой технологии не достаточно одного лишь поддерживающего ее процессора, необходимо также наличие соответствующих чипсетов материнской платы, BIOS и программного обеспечения, использующего Intel VT. Список поддерживающих Intel VT процессоров приведен далее:

Процессоры для настольных платформ:

Процессоры для ноутбуков:

Процессоры для серверных платформ:

Компания Intel планирует также развивать технологию под названием Virtualization for Directed I/O к Intel VT, имеющую версию VT-d. На данный момент известно, что это существенные изменения в архитектуре ввода-вывода, которые позволят улучшить защищенность, робастность и производительность виртуальных платформ, использующих аппаратные техники виртуализации.

Виртуализация AMD

Компания AMD, так же, как и компания Intel, не так давно взялась за доработку архитектуры процессоров с целью поддержки виртуализации. В мае 2005 года компания AMD объявила о начале внедрения поддержки виртуализации в процессоры. Официальное название, которое получила новая технология — AMD Virtualization (сокращенно AMD-V), а ее внутреннее кодовое имя — AMD Pacifica. Технология AMD-V является логическим продолжением технологии Direct Connect для процессоров AMD64, направленной на повышение производительности компьютерных систем за счет тесной прямой интеграции процессора с другими компонентами аппаратного обеспечения.

В списке далее приведены процессоры, поддерживающие функции аппаратной виртуализации AMD-V. Поддержка этих функций должна работать во всех процессорах серии AMD-V для настольных компьютеров под Socket AM2, начиная со степпинга F. Необходимо также отметить, что процессоры Sempron не поддерживают аппаратную виртуализацию.

Процессоры для настольных платформ:

Для ноутбуков поддерживаются процессоры с брендом Turion 64 X2:

Для серверных платформ поддерживаются следующие процессоры Opteron:

Программное обеспечение, поддерживающее аппаратную виртуализацию

На данный момент, абсолютное большинство вендоров программных платформ виртуализации заявило о поддержке технологий аппаратной виртуализации Intel и AMD. Виртуальные машины на этих платформах могут быть запущены при поддержке аппаратной виртуализации. Кроме того, во многих операционных системах, в дистрибутив которых включены программные платформы паравиртуализации, такие как Xen или Virtual Iron, аппаратная виртуализация позволит запускать неизмененные гостевые операционные системы. Так как паравиртуализация является одним из видов виртуализации, требующих модификации гостевой операционной системы, реализация в платформах паравиртуализации поддержки аппаратной виртуализации является для этих платформ весьма приемлемым решением, с точки зрения возможности запуска не модифицированных версий гостевых систем. В приведенной далее таблице перечислены основные популярные платформы виртуализации и программное обеспечение, поддерживающие технологии аппаратной виртуализации:

Аппаратная виртуализация сегодня

Компания VMware, входящая в исследовательскую группу аппаратных техник виртуализации, в конце 2006 года провела исследование в отношении собственной программной виртуализации в сравнении с аппаратными технологиями виртуализации компании Intel. В документе «A Comparison of Software and Hardware Techniques for x86 Virtualization» были зафиксированы результаты этого исследования (на процессоре 3.8 GHz Intel Pentium 4 672 с отключенной технологией Hyper-Threading). Один из экспериментов проводился с помощью систем тестов SPECint2000 и SPECjbb2005, являющихся стандартом де-факто для оценки производительности компьютерных систем. В качестве гостевой системы использовалась ОС Red Hat Enterprise Linux 3, управляемая программным и аппаратным гипервизором. Ожидалось, что аппаратная виртуализация даст коэффициент производительности около ста процентов в отношении нативного запуска операционной системы. Однако результаты оказались весьма неожиданными: в то время как программный гипервизор без использования аппаратных техник виртуализации давал 4 процента потерь производительности в отношении нативного запуска, аппаратный гипервизор, в целом, терял 5 процентов производительности. Результаты этого теста приведены на рисунке далее:

Выводы

Поддержка технологий аппаратной виртуализации в процессорах открывает широкие перспективы по использованию виртуальных машин в качестве надежных, защищенных и гибких инструментов для повышения эффективности виртуальных инфраструктур. Наличие поддержки аппаратных техник виртуализации в процессорах не только серверных, но и настольных систем, говорит о серьезности намерений производителей процессоров в отношении всех сегментов рынка пользователей компьютерных систем. Использование аппаратной виртуализации в перспективе должно уменьшить потери производительности при запуске нескольких виртуальных машин на одном физическом сервере. Безусловно, аппаратная виртуализация повысит защищенность виртуальных систем в корпоративных средах. Сейчас простота разработки платформ виртуализации с использованием аппаратных техник привела к появлению новых игроков на рынке средств виртуализации. Вендоры систем паравиртуализации широко применяют аппаратную виртуализацию для запуска не модифицированных гостевых систем. Дополнительным преимуществом аппаратных техник виртуализации является возможность запуска 64-битных гостевых систем на 32-битных версиях платформ виртуализации (например, VMware ESX Server).

Не стоит воспринимать результаты производительности, как единственно верные. Объективная оценка производительности различных аппаратных и программных платформ для виртуализации является нетривиальной задачей, упомянутая рабочая группа в составе SPEC работает над созданием набора стандартных методов для оценки таких систем. На сегодня можно отметить, что средства виртуализации от AMD являются технически более совершенными, нежели реализованные Intel. Многое зависит и от используемого ПО, к примеру, в отличие от VMWare, есть значительно более «отзывчивые» к аппаратной поддержке среды, например, Xen 3.0.

Источник

Аппаратная виртуализация. Теория, реальность и поддержка в архитектурах процессоров

Введение

Виртуализация представляла интерес ещё до изобретения микропроцессора, во времена преобладания больших систем — мейэнфреймов, ресурсы которых были очень дорогими, и их простой был экономически недопустим. Виртуализация позволяла повысить степень утилизации таких систем, при этом избавив пользователей и прикладных программистов от необходимости переписывать своё ПО, так как с их точки зрения виртуальная машина была идентична физической. Пионером в этой области являлась фирма IBM с мэйнфреймами System/360, System/370, созданными в 1960-1970-х гг.

Классический критерий виртуализуемости

Неудивительно, что критерии возможности создания эффективного монитора виртуальных машин были получены примерно в то же время. Они сформулированы в классической работе 1974 г. Жеральда Попека и Роберта Голдберга «Formal requirements for virtualizable third generation architectures» [8]. Рассмотрим её основные предпосылки и сформулируем её основной вывод.

Модель системы

В дальнейшем используется упрощённое представление «стандартной» ЭВМ из статьи, состоящей из одного центрального процессора и линейной однородной оперативной памяти. Периферийные устройства, а также средства взаимодействия с ними опускаются. Процессор поддерживает два режима работы: режим супервизора, используемый операционной системой, и режим пользователя, в котором исполняются прикладные приложения. Память поддерживает режим сегментации, используемый для организации виртуальной памяти.
Выдвигаемые требования на монитор виртуальных машин (ВМ):

Классы инструкций

Достаточное условие построения монитора ВМ

Рис. 1: Выполнение условия виртуализуемости. Множество служебных инструкций является подмножеством привилегированных

Ограничения применимости критерия виртуализуемости

Несмотря на простоту использованной модели и полученных из неё выводов, работа Голдберга и Попека является актуальной до сих пор. Следует отметить, что несоблюдение описанных в ней условий вовсе не делает создание или использование виртуальных машин на некоторой архитектуре принципиально невозможным, и есть практические примеры реализаций, подтверждающие это. Однако соблюсти оптимальный баланс между тремя свойствами: изоляцией, эквивалентностью и эффективностью, — становится невозможным. Чаще всего расплачиваться приходится скоростью работы виртуальных машин из-за необходимости тщательного поиска и программного контроля за исполнением ими служебных, но не привилегированных инструкций, так как сама аппаратура не обеспечивает этого (рис. 2). Даже единственная такая инструкция, исполненная напрямую ВМ, угрожает стабильной работе монитора, и поэтому он вынужден сканировать весь поток гостевых инструкций.

Рис. 2: Невыполнение условия виртуализуемости. Служебные, но не привилегированные инструкции требуют реализации сложной логики в мониторе

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

Структура гостевых программ

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

Периферия

Поскольку периферийные устройства являются служебным ресурсом ЭВМ, очевидно, что для обеспечения условий изоляции и эквивалентности необходимо, чтобы все попытки доступа к ним были контролируемы монитором ВМ так же, как они контролируются в многозадачной операционной системе её ядром. В настоящее время доступ к устройствам чаще всего производится через механизм отражения их в физической памяти системы (англ. memory mapped I/O), что означает, что внутри монитора это чтение/запись некоторых регионов должно или вызывать ловушку защиты памяти, или быть не служебным, т.е. не вызывать ловушку и не влиять на состояние неконтролируемым образом.
Интенсивность взаимодействия приложений с периферией может быть различна и определяется их функциональностью, что сказывается на их замедлении при виртуализации. Кроме того, монитор ВМ может делать различные классы периферии, присутствующей на хозяине, доступными внутри нескольких ВМ различными способами.

Прерывания

Прерывания являются механизмом оповещения процессора о событиях внешних устройств, требующих внимания операционной системы. В случае использования виртуальных машин монитор должен иметь возможность контролировать доставку прерываний, так как часть или все из них необходимо обрабатывать именно внутри монитора. Например, прерывание таймера может быть использовано им для отслеживания/ограничения использования гостями процессорного времени и для возможности переключения между несколькими одновременно запущенными ВМ. Кроме того, в случае нескольких гостей заранее неясно, какому из них следует доставить прерывание, и принять решение должен монитор.
Простейшее решение, обеспечивающее изоляцию, — это направлять все прерывания в монитор ВМ. Эквивалентность при этом будет обеспечиваться им самим: прерывание при необходимости будет доставлено внутрь гостя через симуляцию изменения его состояния. Монитор может дополнительно создавать виртуальные прерывания, обусловленные только логикой его работы, а не внешними событиями. Однако эффективность такого решения не будет оптимальной. Как правило, реакция системы на прерывание должна произойти в течение ограниченного времени, иначе она потеряет смысл для внешнего устройства или будет иметь катастрофические последствия для системы в целом. Введение слоя виртуализации увеличивает задержку между моментом возникновения события и моментом его обработки в госте по сравнению с системой без виртуализации. Более эффективным является аппаратный контроль за доставкой прерываний, позволяющий часть из них сделать безвредными для состояния системы и не требовать каждый раз вмешательства программы монитора.

Многопроцессорные системы

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

Синхронизация и виртуализация

Введение в рассмотрение нескольких хозяйских и гостевых процессоров оставляет условие эффективной виртуализуемости в силе. Однако необходимо обратить внимание на выполнение условий эффективности работы многопоточных приложений внутри ВМ. В отличие от однопоточных, для них характерны процессы синхронизации частей программы, исполняющихся на различных виртуальных процессорах. При этом все участвующие потоки ожидают, когда все они достигнут заранее определённой точки алгоритма, т.н. барьера. В случае виртуализации системы один или несколько гостевых потоков могут оказаться неактивными, вытесненными монитором, из-за чего остальные будут попусту тратить время.
Примером такого неэффективного поведения гостевых систем является синхронизация с задействованием циклических блокировок (англ. spin lock) внутри ВМ [9]. Будучи неэффективной и поэтому неиспользуемой для однопроцессорных систем, в случае нескольких процессоров она является легковесной альтернативой другим, более тяжеловесным замкам (англ. lock), используемым для входа в критические секции параллельных алгоритмов. Чаще всего они используются внутри операционной системы, но не пользовательских программ, так как только ОС может точно определить, какие из системных ресурсов могут быть эффективно защищены с помощью циклических блокировок. Однако в случае виртуальной машины планированием ресурсов на самом деле занимается не ОС, а монитор ВМ, который в общем случае не осведомлён о них и может вытеснить поток, способный освободить ресурс, тогда как второй поток будет выполнять циклическую блокировку, бесполезно тратя процессорное время. Оптимальным решением при этом является деактивация заблокированного потока до тех пор, пока нужный ему ресурс не освободится.

Прерывания в многопроцессорных системах

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

Преобразование адресов

Модель машинных инструкций, использованная ранее для формулировки утверждения об эффективной виртуализации, использовала простую линейную схему трансляции адресов, основанную на сегментации, популярную в 70-х годах прошлого века. Она является вычислительно простой, не изменяется при введении монитора ВМ, и поэтому анализа влияния механизма преобразования адресов на эффективность не производилось.
В настоящее время механизмы страничной виртуальной памяти и применяют нелинейное преобразование виртуальных адресов пользовательских приложений в физические адреса, используемые аппаратурой. Участвующий при этом системный ресурс — регистр-указатель адреса таблицы преобразований (чаще всего на практике используется несколько таблиц, образующих иерархию, имеющую общий корень). В случае работы ВМ этот указатель необходимо виртуализовать, так как у каждой гостевой системы содержимое регистра своё, как и положение/содержимое таблицы. Стоимость программной реализации этого механизма внутри монитора высока, поэтому приложения, активно использующие память, могут терять в эффективности при виртуализации.
Для решения этой проблемы используется двухуровневая аппаратная трансляция адресов (рис. 3). Гостевые ОС видят только первый уровень, тогда как генерируемый для них физический адрес в дальнейшем транслируется вторым уровнем в настоящий адрес.

Рис. 3: Двухуровневая трансляция адресов. Первый уровень контролируется гостевыми ОС, второй — монитором виртуальных машин

Другой ресурс ЭВМ, отвечающий за преобразование адресов, — это буфер ассоциативной трансляции (англ. translation lookaside buffer, TLB), состоящий из нескольких записей. Каждая гостевая система имеет своё содержимое TLB, поэтому при смене активной ВМ или переходе в монитор он должен быть сброшен. Это негативно сказывается на производительности систем, так как восстановление его содержимого требует времени, в течение которого приходится использовать менее эффективное обращение к таблице трансляций адресов, расположенной в памяти.
Решение состоит в разделении ресурсов TLB между всеми системами [10]. Каждая строка буфера ассоциируется с идентификатором — тэгом, уникальным для каждой ВМ. При поиске в нём аппаратурой учитываются только строки, тэг которых соответствует текущей ВМ.

Преобразование адресов для периферийных устройств

Кроме процессоров к оперативной памяти напрямую могут обращаться и периферийные устройства — с помощью технологии DMA (англ. direct memory access). При этом обращения в классических системах без виртуализации идёт по физическим адресам. Очевидно, что внутри виртуальной машины необходимо транслировать такие адреса, что превращается в накладные расходы и понижение эффективности монитора.
Решение состоит в использовании устройства IOMMU (англ. Input output memory management unit), позволяющего контролировать обращения хозяйских устройств к физической памяти.

Расширение принципа

Расширим условие виртуализуемости, заменив в нём слово «инструкция» на «операция»: множество служебных операций является подмножеством привилегированных. При этом под операцией будем подразумевать любую архитектурно определённую активность по чтению или изменению состояния системы, в том числе инструкции, прерывания, доступы к устройствам, преобразования адресов и т.п.
При этом условие повышения эффективности виртуализации будет звучать следующим образом: в архитектуре системы должно присутствовать минимальное число служебных операций. Достигать его можно двумя способами: переводя служебные инструкции в разряд безвредных или уменьшая число привилегированных. Для этого большинство архитектур пошло по пути добавления в регистр состояния M нового режима r — режима монитора ВМ (англ. root mode). Он соотносится с режимом s так, как s — с u; другими словами, обновлёный класс привилегированных инструкций теперь вызывает ловушку потока управления, переводящую процессор из s в r.

Статус поддержки в современных архитектурах

Рассмотрим основные современные архитектуры вычислительных систем, используемых на серверах, рабочих станциях, а также во встраиваемых системах, с точки зрения практической реализации описанных выше теоретических принципов. См. также серию статей [5,6,7].

IBM POWER

Компания IBM была одной из первых, выведших архитектуру с аппаратной поддержкой виртуализации на рынок серверных микропроцессоров в серии POWER4 в 2001 году. Она предназначалась для создания изолированных логических разделов (англ. logical partitions, LPAR), с каждым из которых ассоциированы один или несколько процессоров и ресурсы ввода-вывода. Для этого в процессор был добавлен новый режим гипервизора к уже присутсвовавшим режимам супервизора и пользователя. Для защиты памяти каждый LPAR ограничен в режиме с отключенной трансляцией адресов и имеет доступ лишь к небольшому приватному региону памяти; для использования остальной памяти гостевая ОС обязана включить трансляцию, контролируемую монитором ВМ.
В 2004 году развитие этой архитектуры, названное POWER5, принесло серьёзные усовершенствования механизмов виртуализации. Так, было добавлено новое устройство таймера, доступное только для монитора ВМ, что позволило ему контролировать гостевые системы более точно и выделять им процессорные ресурсы с точностью до сотой доли от процессора. Также монитор ВМ получил возможность контролировать адрес доставки прерываний — в LPAR или в гипервизор. Самым важным же нововведением являлся тот факт, что присутствие гипервизора являлось обязательным — он загружался и управлял системными ресурсами, даже если в системе присутствовал единственный LPAR-раздел. Поддерживаемые ОС (AIX, Linux, IBM i) были модифицированы с учётом этого, чтобы поддерживать своеобразную паравиртуализационную схему. Для управления устройствами ввода-вывода один (или два, для балансировки нагрузки) из LPAR загружает специальную операционную систему — virtual I/O server (VIOS), предоставляющую эти ресурсы для остальных разделов.

SPARC

Компания Sun, развивавшая системы UltraSPARC и ОС Solaris, предлагала виртуализацию уровня ОС (т.н. контейнеры или зоны) начиная с 2004 г. В 2005 году в многопоточных процессорах Niagara 1 была представлена аппаратная виртуализация. При этом гранулярность виртуализации была равна одному потоку (всего чип имел восемь ядер, четыре потока на каждом).
Для взаимодействия ОС и гипервизора был представлен публичный и стабильный интерфейс для привилегированных приложений [3], скрывающий от ОС большинство архитектурных регистров.
Для трансляции адресов используется описанная ранее двухуровневая схема с виртуальными, реальными и физическими адресами. При этом TLB не хранит промежуточный адрес трансляции.

Intel IA-32 и AMD AMD64

В отличие от POWER и SPARC, архитектура IA-32 (и её расширение AMD64) никогда не была подконтрольна одной компании, которая могла бы добавлять функциональность (пара)виртуализации между аппаратурой и ОС, нарушающую обратную совместимость с существующими операционными системами. Кроме того, в ней явно нарушены условия эффективной виртуализации — около 17 служебных инструкций не являются привилегированными, что мешало создать аппаратно поддерживаемые мониторы ВМ. Однако программные мониторы существовали и до 2006 года, когда Intel представила технологию VT-x, а AMD — похожую, но несовместимую с ней AMD-V.
Были представлены новые режимы процессора — VMX root и non root, и уже существовавшие режимы привилегий 0-3 могут быть использованы в обоих из них. Переход между режимами может быть осуществлён с помощью новых инструкций vmxon и vmxoff.
Для хранения состояния гостевых систем и монитора используется новая структура VMCS (англ. virtual machine control structure), копии которой размещены в физической памяти и доступны для монитора ВМ.
Интересным решением является конфигурируемость того, какие события в госте будут вызывать событие ловушки и переход в гипервизор, а какие оставлены на обработку ОС. Например, для каждого гостя можно выбрать, будут ли внешние прерывания обрабатываться им или монитором; запись в какие биты контрольных регистров CR0 и CR4 будет перехватываться; какие исключения должны обрабатываться гостём, а какие — монитором и т.п. Данное решение позволяет добиваться компромисса между степенью контроля над каждой ВМ и эффективностью виртуализации. Таким образом, для доверенных гостей контроль монитора может быть ослаблен, тогда как одновременно исполняющиеся с ними сторонние ОС будут всё так же под его строгим наблюдением. Для оптимизации работы TLB используется описанная выше техника тэгирования его записей с помощью ASID (англ. address space identifier). Для ускорения процесса трансляции адресов двухуровневая схема трансляции получила имя Intel EPT (англ. extended page walk).

Intel IA-64 (Itanium)

Intel добавила аппаратную виртуализацию в Itanium (технология VT-i [4]) одновременно с IA-32 — в 2006 году. Специальный режим включался с помощью нового бита в статусном регистре PRS.vm. С включенным битом ранее служебные, но не привилегированные инструкции начинают вызывать ловушку и выход в монитор. Для возвращения в режим гостевой ОС используется инструкция vmsw. Часть инструкций, являющаяся служебными, при включенном режиме виртуализации генерируют новый вид синхронного исключения, для которого выделен собственный обработчик.
Поскольку операционная система обращается к аппаратуре посредством специального интерфейса PAL (англ. processor abstraction level), последний был расширен, чтобы поддерживать такие операции, как создание и уничтожение окружений для гостевых систем, сохранение и загрузка их состояния, конфигурирование виртуальных ресурсов и т.д. Можно отметить, что добавление аппаратной виртуализации в IA-64 потребовало меньшего количества усилий по сравнению с IA-32.

Архитектура ARM изначально была предназначена для встраиваемых и мобильных систем, эффективная виртуализация которых, по сравнению с серверными системами, долгое время не являлась ключевым фактором коммерческого и технологического успеха. Однако в последние годы наметилась тенденция к использованию ВМ на мобильных устройствах для обеспечения защиты критически важных частей системного кода, например, криптографических ключей, используемых при обработке коммерческих транзакций. Кроме того, процессоры ARM стали продвигаться на рынок серверных систем, и это потребовало расширить архитектуру и добавить в неё такие возможности, как поддержка адресации больших объёмов памяти и виртуализация.
Оба аспекта были отражены в избранном компанией ARM подходе к развитию своей архитектуры. На рис. 4 представлена схема, подразумевающая вложенность двух уровней виртуализации, представленная в 2010 году в обновлении архитектуры Cortex A15 [1].

Рис. 4: Виртуализация ARM. Монитор TrustZone обеспечивает изоляцию и криптографическую аутентификацию доверенного «мира». В обычном «мире» используется собственный монитор ВМ

Для обеспечения изоляции критических компонент используется первый слой виртуализации, называемый TrustZone. С его помощью все запущенные программные компоненты делятся на два «мира» — доверенный и обычный. В первой среде исполняются те части системы, работа которых не должна быть подвластна внешним влияниям обычного кода. Во второй среде исполняются пользовательские приложения и операционная система, которые теоретически могут быть скомпрометированы. Однако обычный «мир» не имеет доступа к доверенному. Монитор TrustZone обеспечивает доступ в обратном направлении, что позволяет доверенному коду контролировать состояние аппаратуры.
Второй слой виртуализации исполняется под управлением недоверенного монитора и предоставляет возможности мультиплексирования работы нескольких пользовательских ОС. В нём добавлены новые инструкции HVC и ERET для входа и выхода в/из режим(а) гипервизора. Для событий ловушки использован ранее зарезервированный вектор прерываний 0x14, добавлены новые регистры: указатель стэка SPSR, состояние виртуальных ресурсов HCR и регистр «синдрома» HSR, в котором хранится причина выхода из гостя в монитор, что позволяет последнему быстро проанализировать ситуацию и проэмулировать необходимую функциональность без избыточного чтения состояния гостя.
Так же, как это сделано в рассмотренных ранее архитектурах, для ускорения механизмов трансляции адресов используется двухуровневая схема, в которой физические адреса гостевых ОС являются промежуточными. Внешние прерывания могут быть настроены как на доставку монитору, который потом перенаправляет их в гость с помощью механизма виртуальных прерываний, так и на прямую отправку в гостевую систему.

Процессоры MIPS развивались в направлении, обратном наблюдаемому для ARM: от высокопроизводительных систем к встраиваемым и мобильным. Тем не менее, аппаратная виртуализация для неё появилась относительно недавно, в 2012 г. Архитектура MIPS R5 принесла режим виртуализации MIPS VZ [2]. Он доступен как для 32-битного, так и для 64-битного варианта архитектуры.
Добавленное архитектурное состояние позволяет хранить контекст ВМ и монитора отдельно. Например, для нужд гипервизора введена копия системного регистра COP0, независимая от копии гостя. Это позволяет оптимизировать время переключения между ними, в то время как переключение между несколькими гостевыми ОС требует обновления COP0 содержимым из памяти и является менее эффективным. Кроме того, часть бит гостевого регистра, описывающие набор возможностей текущего варианта архитектуры и потому ранее используемые только для чтения, из режима монитора доступны для записи, что позволяет ему декларировать возможности, отличные от действительно присутствующих на хозяине.
Привилегии гипервизора, операционной системы и пользователя образуют т.н. луковую (англ. onion) модель. В ней обработка прерываний идёт снаружи внутрь, т.е. сначала каждое из них проверяется на соответствие правилам монитора, затем ОС. Синхронные исключения (ловушки), наоборот, обрабатываются сперва ОС, а затем монитором.
Так же, как это сделано в рассмотренных ранее архитектурах, для ускорения механизмов трансляции адресов используют тэги в TLB и двухуровневую трансляцию в MMU. Для поддержки разработки паравиртуализационных гостей добавлена новая инструкция hypercall, вызывающая ловушку и выход в режим монитора.

Дополнительные темы

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

Уменьшение частоты и выходов в режим монитора с помощью предпросмотра инструкций

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

Таблица 1. Длительность перехода между режимами аппаратной виртуализации для различных поколений микроархитектур процессоров Intel IA-32 (данные взяты из [11])

Если прямое исполнение с использованием виртуализации оказывается неэффективным, имеет смысл переключиться на другую схему работы, например, на интерпретацию или двоичную трансляцию (см. мою серию постов на IDZ: 1, 2, 3).
На практике исполнения ОС характерна ситуация, что инструкции, вызывающие ловушки потока управления, образуют кластера, в которых две или более из них находятся недалеко друг от друга, тогда как расстояние между кластерами значительно. В следующем блоке кода для IA-32 приведён пример такого кластера. Звёздочкой обозначены все инструкции, вызывающие выход в монитор.

Для того, чтобы избежать повторения сценария: выход из ВМ в монитор, интерпретация инструкции, обратный вход в ВМ только для того, чтобы на следующей инструкции вновь выйти в монитор, — используется предпросмотр инструкций [11]. После обработки ловушки, прежде чем монитор передаст управление обратно в ВМ, поток инструкций просматривается на несколько инструкций вперёд в поисках привилегированных инструкций. Если они обнаружены, симуляция на некоторое время переключается в режим двоичной трансляции. Тем самым избегается негативное влияние эффекта кластеризации привилегированных инструкций.

Рекурсивная виртуализация

Ситуация, когда монитор виртуальных машин запускается под управлением другого монитора, непосредственно исполняющегося на аппаратуре, называется рекурсивной виртуализацией. Теоретически она может быть не ограничена только двумя уровнями — внутри каждого монитора ВМ может исполняться следующий, тем самым образуя иерархию гипервизоров.
Возможность запуска одного гипервизора под управлением монитора ВМ (или, что тоже самое, симулятора) имеет практическую ценность. Любой монитор ВМ — достаточно сложная программа, к которой обычные методы отладки приложений и даже ОС неприменимы, т.к. он загружается очень рано в процессе работы системы, когда отладчик подключить затруднительно. Исполнение под управлением симулятора позволяет инспектировать и контролировать его работу с самой первой инструкции.
Голдберг и Попек в своей упомянутой ранее работе рассмотрели вопросы эффективной поддержки в том числе и рекурсивной виртуализации. Однако их выводы, к сожалению, не учитывают многие из упомянутых выше особенностей современных систем.
Рассмотрим одно из затруднений, связанных со спецификой вложенного запуска мониторов ВМ — обработку ловушек и прерываний. В простейшем случае за обработку всех типов исключительных ситуаций всегда отвечает самый внешний монитор, задача которого — или обработать событие самостоятельно, тем самым «спрятав» его от остальных уровней, или передать его следующему.
Как для прерываний, так и для ловушек это часто оказывается неоптимальным — событие должно пройти несколько уровней иерархии, каждый из которых внесёт задержку на его обработку. На рис. 5 показана обработка двух типов сообщений — прерывания, возникшего во внешней аппаратуре, и ловушки потока управления, случившейся внутри приложения.

Рис. 5: Рекурсивная виртуализация. Все события должны обрабатываться внешним монитором, который спускает их вниз по иерархии, при этом формируется задержка

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

Поддержка рекурсивной виртуализации в существующих решениях

Задаче аппаратной поддержки второго и более уровней вложенности виртуализации производители процессоров уделяют значительно меньше внимания, чем первому её уровню. Тем не менее такие работы существуют. Так, ещё в восьмидесятых годах двадцатого века для систем IBM/370 [13] была реализована возможность запуска копий системного ПО внутри уже работающей на аппаратуре операционной системы. Для этой задачи была введена инструкция SIE (англ. start interpreted execution) [14]. Существуют предложения об интерфейсе между вложенными уровнями виртуализации [12], который позволил бы эффективно поддерживать вложенность нескольких мониторов ВМ, и реализация рекурсивной виртуализации для IA-32 [15]. Однако современные архитектуры процессоров всё же ограничиваются аппаратной поддержкой максимум одного уровня виртуализации.

Источник