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

19 Июл 2014

Клонирование как метод виртуализации

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

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

Рост частоты процессора и частоты Front Side Bus за 15 лет развития компьютерной техники
Рост частоты процессора (желтая линия) и частоты Front Side Bus (сиреневая линия)
в период с 1991 года по 2006 год

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

Виртуализация: составляющие успеха

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

В 2007 году базисная конфигурация распределения ресурсов была дополнена виртуализацией ввода/вывода и сервисом адресной трансляции.  В их задачи входит, если можно так сказать,  «аппаратная» виртуализация процессов, связанных с работой bus-master устройств. В базисной модели эти обязанности выполнял софт, что существенно снижало производительность системы и напоминало борьбу Винни-Пуха с запасами меда — сколько не дай, все мало и мгновенно съедается.

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

Клонирование физических устройств на виртуальные копии в рамках одной хост-системы по­лу­чи­ло название «Технология SR-IOV (Single-Root I/O Virtualization)». Слово Single — ключевое в данном контексте. Аналогичный процесс в кластерной среде называется MR-IOV (Multi-Root I/O Virtualization), и его рассмотрение выходит за рамки нашей статьи.

Отметим, что в отличие от технологии Intel VT-d,  которая поддерживается в системной логике централизованно, SR-IOV поддерживается децентрализовано. Клонирование должно обеспечиваться ресурсами периферийных PCIe-устройств и их драйверами. Это могут быть контроллеры локальной сети, USB3 хост-контроллеры или другие устройства, подключенные к PCIe-шине

О проблеме разделения доступа

Представим, что на вычислительной платформе работают две гостевые ОС. К USB-контроллеру подключено два физических устройства. По условию задачи, устройство №1 необходимо предоставить первой ОС, устройство №2 — второй ОС. Очевидно, каждая из гостевых ОС, для обеспечения доступа к своему устройству, должна иметь доступ к контроллеру универсальной последовательной шины. Но супервизор не может дать такой доступ одновременно и сразу двум задачам. В лучшем случае это приведет к тому, что задачи будут «видеть» чужие устройства, в худшем случае, произойдет фатальный сбой из-за того, что на USB-контроллер одновременно будут поступать два не согласованных между собой потока управляющих воздействий от двух гостевых ОС.

Intel VT как программная репликация

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

Формула успеха «Intel VT плюс SR-IOV = Аппаратная репликация»

Технология SR-IOV обеспечивает аппаратный арбитраж для рассматриваемой ситуации. При этом в конфигурационном пространстве физически присутствуют контроллер PF0 (Physical Function 0) и виртуальные контроллеры VF1-n (Virtual Functions 1…N). Супервизор может передавать в распоряжение каждой гостевой ОС по одной виртуальной функции (аппаратной копии физического контроллера). Аппаратура гарантирует корректный арбитраж взаимно несогласованных потоков управляющих воздействий, поступающих от гостевых ОС на виртуальные копии контроллера. Контроллер PF0 остается в распоряжении супервизора.

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

  1. Low-touch registers: к этим регистрам обращение происходит редко, обычно только при инициализации, их можно эмулировать программно без ущерба для производительности.
  2. High-touch registers: к этим регистрам во время рабочего сеанса обращение происходит интенсивно, поэтому их арбитраж нужно обслуживать аппаратно.

Декларация поддержки устройством технологии SR-IOV, включение заданного количества виртуальных функций, выделение им адресных диапазонов и ряд других операций выполняется с помощью регистрового блока SR-IOV Capability Structure. Приятной новостью для разработчиков диагностического программного обеспечения и всех исследователей современных платформ является то, что метод локализации данного блока в конфигурационном пространстве и назначение его битов унифицируются и подробно оговариваются в спецификациях PCI Express и SR-IOV. Это значит, что даже при отсутствии документации на некий набор системной логики или дискретный периферийный контроллер, можно определить наличие поддержки SR-IOV и дополнительные параметры, а также включить виртуальную функцию и увидеть результат в адресном пространстве. Но заметим, что спецификация SR-IOV определяет механизм создания  виртуальных функций в адресном пространстве, а на приведенном примере с USB, очевидно, что требуется еще один механизм - для разделения доступа созданных виртуальных функций к их дочерним устройствам, чтобы каждая гостевая ОС «видела» только свои USB устройства. Такой механизм не оговаривается спецификацией SR-IOV, а является частью спецификации на конкретное устройство или класс устройств. Так, например, контроллер USB3 XHCI для этого использует регистровый блок xHCI-IOV Capability Structure.

Инициализация виртуальных устройств

Операция Function Level Reset (FLR) обеспечивает сброс на уровне PCI функции. При работе гостевой ОС может возникнуть необходимость программно инициировать сброс и ре-инициализацию устройства, например, для восстановления после фатальной ошибки. Очевидно, что выполнить такой сброс обычным образом нельзя — это повлияет на функционирование данного устройства в других гостевых ОС и супервизоре. Операция Function Level Reset позволяет выполнить изолированный сброс одного виртуального устройства, точнее функции.

Технология масштабирования PCIe-устройств

Режим Alternative Routing-ID Interpretation (ARI) позволяет увеличить количество адресуемых PCI функций на устройство с 8 до 256. Так как виртуальные копии физического устройства создаются на уровне функций, увеличивая количество функций, мы увеличиваем доступное количество виртуальных устройств. Напомним, что по классическим правилам адресации конфигурационного пространства PCI, используется 8-битный номер шины (bus number), 5-битный номер устройства (device number) и 3-битный номер функции (function number). Соответственно, доступно 256 шин, 32 устройства на шину, 8 функций на устройство. В режиме ARI номер устройства не передается, а его 5 бит используются для расширения номера функции. Номер функции становится 8-битным (3+5=8), соответственно доступно 256 функций. Не передавать номер устройства можно в случаях, когда на шине имеется только одно устройство, эта ситуация типична для портов PCI express.

Справочная литература

1. Первоисточником является документ спецификация SR-IOV.

2. Наглядное и компактное представление основных положений спецификации SR-IOV содержится в презентациях:

3. Механизмы, являющиеся частью спецификации шины PCI Express, в частности Function Level Reset (FLR) и Alternative Routing-ID Interpretation (ARI) описаны в PCI-спецификации.

4. Ряд контроллеров локальной сети Intel поддерживают технологию SR-IOV, например Intel 82576 SR-IOV Driver Companion Guide.

5. Хорошим примером имплементации SR-IOV, является спецификация USB3 xHCI. Поддержка виртуализации изначально предусматривалась при разработке данного контроллера, поэтому он относится к типу устройств, называемому natively shared devices.