Виртуализация USB — все включено

23 Янв 2013

Виртуализация USB — все включено

Как известно, основным новшеством спецификации USB 3.0, стало увеличение скорости передачи данных до 5.0 Gbit/s в режиме SuperSpeed. Также усовершенствованы режимы питания USB-устройств от порта, добавлены механизмы, повышающие производительность дисковых накопителей, подключенных по USB-шине. Но огромный потенциал, заложенный в новый стандарт, не ограничивается технологиями высших достижений. Документ дает четкую перспективу внедрения механизмов виртуализации USB-контроллера.

В какой мере проблема виртуализации является критичной для персональных платформ? Другими словами: насколько это важно и кому это нужно? Не будем торопиться  с выводами. Отметим только, что до сих пор решение подобных проблем возлагалось на специальную аппаратуру типа AnywhereUSB, производства Digi International. В итоге пользователь получал USB over IP и запредельно-недружелюбную цену такого девайса, сопоставимую с ценой платформы.

Спецификация USB 3.0 снимает это заклятие и размораживает процесс дальнейшей виртуализации универсальной шины. Внедрение нового стандарта потребовало разработки современного хост-контроллера. Так появился USB 3.0 xHCI (eXtensible Host Controller Interface). Его разработчики изначально оптимизировали архитектуру контроллера для поддержки виртуализации, создав новый тип устройств, часто называемый natively shared devices.

В ранее опубликованной статье «Клонирование устройств как метод виртуализации» мы рассмотрели теоретические предпосылки для виртуализации периферийных устройств. Проанализируем реализацию технологии SR-IOV на примере контроллера USB 3.0 xHCI. Сразу оговоримся, что поддержка SR-IOV для xHCI опциональна, и далеко не все реализации контроллеров обладают соответствующей функциональностью.

О кооперации SR-IOV и Intel VT-x

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

Смысл технологии SR-IOV — аппаратная реализация арбитража доступа нескольких гостевых задач к одному физическому устройству. Для этого, в адресном пространстве создается несколько копий устройства, подлежащего виртуализации, и каждая гостевая задача получает в собственное распоряжение одну из таких копий. Очевидно, каждая копия должна располагаться по уникальному адресу. Если речь об xHCI, то копированию подвергаются регистры конфигурационного пространства и регистры Memory Mapped I/O, управляющие функционированием контроллера.

Вспомним, что механизмы управления памятью и виртуализации, входящие в состав центрального процессора, используют разбиение виртуального и физического адресных пространств на страницы размером 4 Килобайта. Это справедливо как для блока страничной трансляции, появившегося еще в 80386, так и для механизмов Intel VT-x. Каждая гостевая ОС работает в своем виртуальном пространстве. Супервизор, управляя содержимым таблиц страничной трансляции, может отобразить любую страницу виртуального пространства на любую страницу физического пространства. Заданную страницу виртуального пространства можно также отметить как не присутствующую. При обращении к такой странице процессор сгенерирует прерывание для обработки данной ситуации.

Формулировка супервизор отдал контроллер в распоряжение гостевой задачи означает, что таблицы страниц подготовлены таким образом, что в виртуальном адресном пространстве гостевой задачи существует страница, при обращении к которой указанная гостевая задача получает физический доступ к регистрам контроллера, в нашем примере, к диапазону xHCI Memory-Mapped I/O.

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

Оптимизация блока xHCI MMIO

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

А теперь вспомним, что регистры контроллера USB 3.0 xHCI делятся на две группы:

  1. Low-touch registers: к этим регистрам обращение происходит редко, их можно эмулировать программно без ущерба для производительности. В нашем примере это блок регистров xHCI Operational Registers.
  2. High-touch registers: к этим регистрам обращение происходит интенсивно, поэтому их требуется обслуживать аппаратно, средствами SR-IOV. В нашем примере это блок регистров xHCI Runtime Registers.

Метод оптимизации прост и очевиден  разместить регистры двух указанных групп в разных 4-килобайтных блоках. В этом случае, механизмы виртуализации, входящие в состав центрального процессора (например, Intel VT-x) использующие 4-килобайтную гранулярность, смогут раздельно назначать оптимальный статус для каждой группы регистров. Именно такой принцип используется для размещения двух указанных групп регистров контроллера xHCI.

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

Виртуализация USB устройств

Создав в адресном пространстве множество аппаратно поддерживаемых виртуальных копий контроллера USB 3.0 xHCI и раздав по одной копии каждой гостевой задаче, мы сделали только половину дела. Необходимо, чтобы каждая гостевая задача имела доступ к своим USB устройствам и не имела доступа к USB устройствам, принадлежащим другим гостевым задачам. Причем, этот механизм должен одинаково эффективно работать как для устройств, подключенных непосредственно к контроллеру (к порту Root Hub) так и подключенных с использованием дополнительных хабов. Сюда входят (позволим себе небольшое терминологическое отступление):

  1. Integrated Hubs — хабы, расположенные на одном кристалле с контроллером xHCI, включая Rate Matching Hub (RMH).
  2. Embedded Hubs — хабы, выполненные в виде отдельных микросхем расположенные на системной плате между контроллером xHCI и разъемами USB.
  3. External Hubs, внешние хабы, подключаемые пользователем.

Для реализации матрицы программно коммутируемых связей между виртуальными хост контроллерами и USB устройствами, используется структура xHCI-IOV Capability Structure, расположенная в блоке конфигурационных регистров.

Контроллер xHCI выделяет каждому USB устройству блок параметров, называемый Device Slot. Этот блок используется для всех операций с устройством, не только для задач виртуализации. В свою очередь, структура xHCI-IOV Capability Structure содержит блок регистров, по одному регистру на каждый Device Slot. Указанные регистры задают атрибуты для устройства, использующего данный Device Slot. Одним из таких атрибутов является номер виртуального хост контроллера, которому принадлежит данное устройство. Записывая значение этого атрибута, супервизор передает заданное устройство заданной гостевой задаче. Заметим, что при использовании дополнительного атрибута Slot Emulated, возможна аппаратная поддержка эмуляции USB устройств, не существующих физически.

Показательно то, что процессы, связанные с физическим подключением и отключением устройств на USB портах, происходящие, с точки зрения процессорного времени, сравнительно редко, обслуживаются с участием механизмов программной эмуляции. Иллюстрацией этого является то, что регистры PORTSC — Port Status/Control, используемые для мониторинга и управления портами, относятся к группе low-touch registers. Только после того, как подключение обслужено, и супервизор передал USB-устройство одной из гостевых задач, вступают в действие механизмы, аппаратно обеспечивающие связь каждой гостевой задачи исключительно со своими USB устройствами.