Спирали аппаратной виртуализации

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

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

Термин «виртуальная машина» был введен в 60-е годы в связи с появлением многопользовательских систем на базе мэйнфреймов, затем технологии виртуализации были усовершенствованы для работы с мини-компьютерами. К концу 80-х годов, когда стоимость оборудования заметно упала и повсеместно распространились персональные компьютеры, интерес к виртуализации снизился, а эти технологии стали считать не более чем фактом компьютерной истории. Однако, как это часто бывает, развитие индустрии пошло по восходящей спирали с возвратом к старым технологиям, но на новом уровне.

Современные серверы намного дешевле и мощнее машин десяти- и тем более двадцатилетней давности, однако совокупные затраты на их обслуживание, поддержку и администрирование остались высокими. Всеобщее стремление, с одной стороны, к консолидации ИТ-ресурсов, а с другой — к их повсеместному, непрерывному и безопасному потреблению стали новыми двигателями развития технологий виртуализации (по данным IDC, если в 2005 году средствами виртуализации было оснащено 276 тыс. серверов, то к 2009-му их число может достичь 1,1 млн.), но уже на новой процессорной платформе.

Еще во времена микропроцессора Intel 80386 существовала программа-монитор виртуальных машин VM/386, а также особый режим V8086 для этого процессора, но все это было предназначено только для запуска сеансов DOS. Реально же работать с различными операционными системами стало возможным только благодаря программным решениям VMware и других разработчиков: архитектура и система команд процессоров x86 не была ориентирована на виртуализацию. И поэтому вполне естественно, что сегодня в виртуализационную «гонку» поспешили включиться и Intel и AMD, сначала предложившие свои расширения архитектуры, а затем включившие средства аппаратной поддержки виртуализации в микропроцессоры.

У истоков

Компания IBM приступила к разработке первых виртуальных машин в 60-х годах, и виртуальная машина рассматривалась тогда как полностью защищенная и изолированная копия ресурсов физической машины, в которой приложения и операционные системы будут вести себя точно так же как, и на реальных аппаратных средствах. Управление гостевыми системами должен был взять на себя монитор виртуальных машин, который обеспечивал виртуализацию процессора, памяти и устройств ввода-вывода, а также изоляцию программ. Впервые для серийной системы полная виртуализация была реализована в программе CP 67 на машине IBM System 360/67. Каждому пользователю или разделу предоставлялся точный виртуальный образ аппаратных ресурсов физической машины и обеспечивалась работа в режиме разделения времени. Однако производительность CP 67 оказалась недостаточной, и было решено встроить средства аппаратной поддержки виртуализации непосредственно в архитектуру нового семейства IBM System 370. Было известно, что, когда гостевая система выполняется непосредственно на реальном процессоре и пытается выполнить привилегированную команду, процессор должен прервать работу и передать управление монитору виртуальных машин, который и должен решить, можно ли выполнить такую команду или необходимо смоделировать ее выполнение другими средствами.

Для машин IBM System 370 была разработана OC VM/370 (монитор виртуальных машин), которая работала в расширенной архитектуре 370-XA, имеющей специальные аппаратные средства (assists, помощники или ускорители), бравшие на себя существенную часть работы монитора по перехвату и эмуляции потенциально опасных команд. Предусматривался особый режим работы процессора (interpretive execution), для входа в который служила привилегированная команда SIE (Start Interpretive Execution), вместе с которой передавалось текущее состояние гостевой системы. При завершении режима интерпретации соответствующим образом корректировалось слово состояния программы PSW [1].

Преобразование команд и адресов памяти выполнялись на аппаратном уровне. Для корректной обработки команд ввода-вывода применялись методы контроля на уровне подканала, а особо «проверенные» (trusted) системы могли выполняться в основном адресном пространстве и обрабатывать прерывания самостоятельно. Дополнительный уровень безопасности обеспечивала защита на уровне сегментов памяти. Аппаратура (всего было реализовано более 100 функций) обеспечивала поддержку виртуальных машин, монитора виртуальных машин, управляющей программы и управления памятью.

Следующим шагом стало создание архитектуры виртуальных машин для корпоративных систем VM/ESA, в которой поддерживалась среда System/370, ESA/390, VM Data Spaces, 370-XA и ESA/370, что было обусловлено высокой стоимостью оборудования и необходимостью миграции программного обеспечения. Механизмы управления памятью получили средство Multiple Domain Facility (MDF), позволявшее выделять гостевым системам отдельные непрерывные области памяти и более эффективно преобразовывать адреса памяти.

На виртуальных системах IBM VM были отработаны идеи и технологии, во многом определившие архитектуры современных решений по виртуализации не только для современных «мэйнфреймов» IBM System z9 и систем на платформе Power, но и для систем на базе микропроцессоров AMD и Intel.

x86

Как уже говорилось, при разработке архитектуры x86 требования виртуализации не учитывались, и это подтверждается наличием небольшого набора команд, которые хотя и не являются привилегированными, но могут серьезно нарушить стабильную работу всей системы. В условиях работы с одной ОС, для которой изначально и создавались эти процессоры, данное обстоятельство не вызывает никаких затруднений, но в виртуальной системе оно становится источником серьезных проблем. Открытость — большой плюс архитектуры x86, благодаря которой тысячи независимых разработчиков создали великое множество различных внешних устройств и драйверов. Однако такое разнообразие сдерживает решение задач виртуализации. Тем не менее усилиями исследователей и специалистов VMware, Microsoft, XenSource и содружества независимых разработчиков многие недостатки платформы x86 с точки зрения виртуализации удалось компенсировать на программном уровне, причем общим ключом к решению является следующий алгоритм [2]:

• безопасные, непривилегированные команды можно выполнять непосредственно на процессоре;
• небезопасные (чувствительные) привилегированные команды следует перехватывать. При попытке виртуальной машины выполнить такую команду в непривилегированном режиме процессор должен выдать прерывание, а монитор виртуальных машин эмулировать эту команду для виртуальной машины;
• небезопасные непривилегированные команды необходимо выявлять, однако в системе команд x86 есть 17 «проблемных» команд, чрезвычайно чувствительных к виртуальному контексту, и их нельзя перехватить. Монитор виртуальных машин должен контролировать работу виртуальной машины и не допускать, чтобы она выполнила такие команды.

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

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

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

Модификация системы команд

Собственные решения AMD V [3] и Intel VT в 2005 — 2006 гг. предложили оба производителя.

Intel VT. Поддержка виртуализации по версии Intel обеспечивается особым режимом VMX процессора. Монитор виртуальных машин выполняется в привилегированном режиме VMX root, а гостевая ОС с меньшими привилегиями — в режиме VMX non-root. Оба режима поддерживают выполнение на всех четырех уровнях (кольцах) полномочий (рис. 1). Вход в виртуальную машину происходит по команде VMRUN, а обратный переход может быть как условным (изменение определенных разрядов регистра), так и безусловным (команда сброса кэш-памяти). Это и определяет основное отличие режимов VMX root и VMX non-root — выполнение небезопасных команд приводит к выходу из виртуальной машины. Состояние процессора отслеживается с помощью особой структуры данных VMCS, содержащей области управления выполнением виртуальной машины (VM-execution control fields), задающие условия выхода из виртуальной машины. Важно быстро определить эти условия, предпринять необходимые действия и возвратить управление гостевой системе. Механизм двустороннего взаимодействия позволяет монитору виртуальных машин не только реагировать, но и инициировать прерывания и исключения в виртуальной машине.

Рис. 1. Новые режимы процессора обеспечивают более высокий уровень привилегий для монитора виртуальных машин 

Компания Intel развивает также технологию аппаратной поддержки защиты LaGrande, охватывающую процессор, набор микросхем, аппаратный модуль безопасности TPM (Trusted Platform Module) и защищенный ввод/вывод.

AMD-V. Функциональность решения от компании AMD базируется на расширении технологии AMD Direct Connect и близка по возможностям Intel VT, однако расширения архитектуры системы команд оказались несовместимыми. В решение AMD поддержка механизмов управления памятью MMU и DMA закладывалась изначально (микропроцессоры AMD уже были оснащены шиной HyperTransport и контроллером DMA), что создавало определенные «идеологические» преимущества до тех пор, пока Intel не обнародовала собственные спецификации преобразований для DMA.

Рис. 2. В AMD-V введеныв гостевой режим, управляющий блок и дополнительные команды

Виртуализация в AMD-V реализуется путем введения гостевого режима процессора Guest Mode, управляющей структуры данных VMCB (Virtual Machine Control Block) и дополнительных команд (рис. 2).

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

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

Память

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

Итак, перед разработчиками стояла следующая задача — обеспечить аппаратную поддержку виртуализации блока управления памятью (MMU). Компания Intel предложила расширенные таблицы страниц (extended page tables, EPT), а AMD — вложенные таблицы страниц (nested page tables, NPT). Основная идея состоит в том, чтобы снять с монитора виртуальных машин часть нагрузки по поддержке целостности отображений теневых таблиц. Для этого, например, в технологии EPT, вводится отдельный набор таблиц страниц, которые поддерживаются на аппаратном уровне и устанавливают соответствие физических адресов гостевой и главной системы. Таким образом, благодаря аппаратной поддержке, отпадает необходимость постоянного переключения между виртуальной машиной и монитором, что в сумме является очень «дорогостоящей» операцией.

Другая задача — ускорение доступа к буферу быстрого преобразования адресов (TLB). Для этого в компании Intel предложили поставить в соответствие каждой виртуальной машине идентификатор виртуального процессора (virtual processor identifier, VPID). В технологии AMD применяется идентификатор адресного пространства (address space identifier, ASID). Если снабдить такими «ключами» cтроки TLB, то можно избежать сброса буфера при каждом входе и выходе из виртуальной машины.

Внешние устройства

Архитектура подсистем ввода-вывода на мэйнфреймах базировалась на концепции канала — доступ к устройствам осуществлялся через отдельный процессор ввода-вывода, поэтому монитор мог безопасно и с низкими накладными расходами предоставить виртуальной машине возможность непосредственного чтения и записи на устройство. Этот подход хорошо работал для текстовых терминалов, дисков, считывателей перфокарт и других преимущественно последовательных устройств того времени. В современных системах разнообразие устройств и их интерфейсов несравненно шире, что существенно затрудняет виртуализацию ввода-вывода: монитор виртуальных машин должен по крайней мере уметь общаться с тысячами устройств различных производителей. К некоторым устройствам, например графическим и сетевым контроллерам (адаптерам), предъявляются чрезвычайно высокие требования по производительности, что также весьма затрудняет виртуализацию.

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

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

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

Рис. 3. Модели виртуализации ввода-вывода

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

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

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

AMD IOMMU. Предложение AMD состоит в том, чтобы обрабатывать виртуальные операции ввода-вывода с помощью битовой матрицы или вектора исключения устройств (device exclusion vector, DEV) — таблицы управления прямым доступом устройств к страницам памяти гостевой системы. Если доступ разрешен, запрос помечается как безопасный, и последующие проверки не производятся. Таким образом, выделенное устройство может получить доступ только к соответствующим страницам памяти «своей» гостевой системы.

Концепция DEV в спецификации AMD IOMMU расширена — теперь каждому устройству может быть назначен специфический домен и собственный набор таблиц страниц ввода-вывода. При попытке чтения или записи в системную память IOMMU прерывает доступ, находит домен, который назначен устройству, и по TLB определяет наличие разрешения доступа и фактический адрес, по которому следует обратиться к памяти.

Рис. 4. Реализация распределенной системы управления памятью ввода-вывода

Факультативно могут поддерживаться удаленные IOTLB — устройства, имеющие IOTLB, могут взаимодействовать с IOMMU при преобразовании адресов, что позволяет создавать масштабируемые системы, в которых есть устройства с различными моделями использования (рис. 4). Локальные TLB соответствуют специфике устройств, и при этом производительность последних не ограничена количеством записей TLB, реализованных в IOMMU.

Intel VT-d. Основные компоненты этого решения — средства преобразования адресов DMA и виртуализация прерываний. Для этого была расширена архитектура модуля управления памятью ввода-вывода IOMMU. Традиционно IOMMU применяется при распределении и сборке областей памяти и размещается в мостах PCI root, а в спецификации VT-d предусматриваются программно определяемые домены (изолированные области физической памяти основной системы), с помощью которых доступ к памяти разрешается только устройствам, ассоциированным с этим доменом. Данный механизм обеспечивает изоляцию и исключение устройств аналогично DEV. Домены защиты могут определяться как для виртуальных машин, так и для драйверов устройств, выполняющихся в мониторе виртуальных машин.

При использовании таблиц виртуальной адресации DVA обеспечивается необходимый уровень изоляции, поскольку доступ к физической памяти разрешается только выделенным устройствам. Для ускорения просмотра предусматривается использование таблицы IOTLB, ключом которой служит триада «шина PCI — устройство — функция». Как только данные записаны в память, гостевой системе направляется уведомление. Заметим, что раньше прерывания передавались через монитор виртуальных машин, что вызывало дополнительные накладные расходы — внешнее устройство могло сигнализировать о прерывании либо с помощью контроллера, либо через сообщение MSI, передаваемое через DMA. Формат этого сообщения в спецификации Intel VT-d переопределен и обеспечивает повышенную степень изоляции. Операции записи DMA содержат идентификаторы сообщения и запрашивающего устройства, и по ним индексируется таблица отображения прерываний. Дополнительные структуры отображения могут быть вложенными, и для ускорения их обработки предусматриваются различные аппаратные средства, в том числе IOTLB и кэширование прерываний. Спецификация обеспечивает защищенный и эффективный доступ выделенных устройств к памяти виртуальных машин, однако, разделение высокопроизводительных устройств пока не реализовано. Компания Intel выполнила большой объем исследований, и теперь работы переданы сообществу производителей устройств и рабочей группе PCI Express Special Interest Group. Эффективность будущих решений будет определяться, с одной стороны, развитием функциональных возможностей собственно процессоров и наборов микросхем, а с другой — совершенствованием программных реализаций мониторов виртуальных машин по использованию средств аппаратной поддержки виртуализации.

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

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

Изоляция систем. Применяется для обеспечения независимости виртуальных машин. Гостевые ОС и приложения распределяются в зависимости от их критичности и функциональных возможностей. Например, в центре обработки данных мультисервисной телекоммуникационной системы компоненты системы информационной безопасности (сетевые экраны) и серверы, поддерживающие обработку голосовых сообщений, разворачиваются в гостевой ОС Linux, а серверы потоковой обработки данных — под управлением Windows Server на единой аппаратной платформе. Для обеспечения отказоустойчивости гостевые ОС могут дублироваться, и тем самым время простоя в случае отказа может быть сведено к минимуму.

Консолидация нагрузки. Используется для объединения физических серверов в виде отдельных виртуальных машин, каждая из которых имеет собственную операционную систему. При этом единый административный интерфейс позволяет организовать эффективное управление физическими и виртуальными ресурсами. Динамическое выделение и перераспределение ресурсов серверадает возможность быстро перемещать выполняющиеся приложения, в зависимости от рабочих нагрузок. Если раньше такая возможность использовалась преимущественно для обеспечения отказоустойчивости, то теперь, в условиях предоставления ресурсов по требованию (utility computing), она становится одной из основных обеспечивающих технологий центров обработки данных.

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

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

***

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

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

Литература

1. R. J. Creasy, The Origin of the VM/370 Time-Sharing System, IBM Journal of Research and Development, Volume 25, 1981.
2. J. S. Robin, C. E. Irvine. Analysis of the Intel Pentium Ability to Support a Secure Virtual Machine Monitor, USENIX Security Symposium, 2000.
3. A. Zeichick, Processor-Based Virtualization, AMD64 Style.