Рыбаков С. А., Поляков Н. Ю

ISSN 2413–9599 (Print) ISSN 2541–870Х (Online)

DOI: 10.21778/2413-9599-2020-30-3-34-39 УДК: 004.451.1

www.radioprom.org

Виртуализация подсистемы вводавывода микропроцессоров «Эльбрус»

С.А. Рыбаков 1, 2 , Н.Ю. Поляков 1

1 АО «МЦСТ», Москва, Россия 2 ФГБОУ ВО «МИРЭА – Российский технологический университет», Москва, Россия

В статье приведено описание и сравнение адаптированных для архитектуры «Эльбрус» методов виртуализации устройств ввода-вывода, входящих в конфигурацию универсальных микропроцессоров. Рассмотренные методы программной эмуляции и паравиртуализации устройств не требуют аппаратной поддержки и обеспечивают полную изоляцию реальных устройств от виртуальных на уровне гипервизора, что позволяет лучше консолидировать физический ввод-вывод. Лучшую производительность по сравнению с другими методами обеспечивает прямое назначение устройства гостю, которое требует аппаратных доработок в блоке управления памятью для операций ввода-вывода (IOMMU). Аппаратная поддержка виртуализации ввода-вывода была реализована в микропроцессорах «Эльбрус-16C» нового поколения. Результаты исследования могут быть применены пользователями виртуализации платформы «Эльбрус» для детальной настройки ввода-вывода виртуальных машин с целью оптимизации каждой гостевой системы под конкретные задачи.

Ключевые слова: виртуализация ввода-вывода, virtio, VFIO, IOMMU, «Эльбрус-16С»

Для цитирования: Рыбаков С. А., Поляков Н. Ю. Виртуализация подсистемы ввода-вывода микропроцессоров «Эльбрус» // Радиопромышленность. 2020. Т. 30, № 3. С. 34–39. DOI: 10.21778/2413-9599-2020-30-3-34-39

© Рыбаков С. А., Поляков Н. Ю., 2020

Input/output virtualization of Elbrus microprocessors

S.A. Rybakov 1, 2 , N. Yu. Polyakov 1

1 JSC MCST, Moscow, Russia 2 MIREA – Russian Technological University, Moscow, Russia

The article describes and compares the methods of input-output (I/O) virtualization, adapted for the Elbrus architecture. The presented methods of software emulation and paravirtualization of devices do not require hardware support and provide complete isolation of real devices from virtual ones at the hypervisor level, which allows for better consolidation of physical I/O. Direct assignment of the device to the guest provides better performance over the other methods, but requires hardware modifications in the I/O Memory Management Unit (IOMMU). Hardware support for I/O virtualization was implemented in the new generation of Elbrus microprocessors. The research results can help the users of the Elbrus platform virtualization to setup a detailed configuration of the virtual machine I/O to optimize each guest system for specific tasks.

Keywords: input-output virtualization, virtio, VFIO, IOMMU, Elbrus-16C

For citation: Rybakov S. A., Polyakov N. Yu. Input/output virtualization of Elbrus microprocessors. Radio industry (Russia), 2020, vol. 30, no. 3, pp. 34–39. (In Russian). DOI: 10.21778/2413-9599-2019-30-3-34-39.

Введение

Виртуализация операционной системы (ОС) – это технология предоставления набора вычислительных ресурсов (процессоров, оперативной памяти, устройств ввода-вывода) гостевым операционным системам с обеспечением их логической изоляции друг от друга. Подсистема ввода-вывода является неотъемлемой частью виртуальной вычислительной системы. Устройства ввода-вывода могут быть эмулированы программно на уровне гипервизора. Гипервизор также может передать реальное устройство в пользование одной из гостевых систем. В данной статье приводится сравнение этих методов виртуализации ввода-вывода.

Полная виртуализация и паравиртуализация

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

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

Интерпозиция ввода-вывода

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

Гипервизор предоставляет гостю набор виртуальных устройств, затем он перехватывает обращения гостя к устройствам ввода-вывода и эмулирует их, используя в том числе и реальные устройства. Такой принцип виртуализации ввода-вывода характеризуется как интерпозиция [1].

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

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

Наконец, при интерпозиции ввода-вывода гипервизор имеет право производить оптимизации физической памяти гостя. Рассмотрим в качестве примера гипервизор ОС «Эльбрус» – пользовательское приложение QEMU (Quick Emulator) [2], взаимодействующее с модулями ядра Linux KVM (Kernel-based Virtual Machine) [3]. С точки зрения ядра ОС физическая память гостя является виртуальной памятью процесса QEMU, и к ней применимы стандартные оптимизации виртуальной памяти Linux (в том числе подкачка страниц по необходимости и откачка памяти на диск). В отличие от методов виртуализации с интерпозицией вводавывода, не накладывающих на эти оптимизации никаких ограничений, рассматриваемый далее метод прямого назначения устройства требует их запрета.

Метод программной эмуляции (полной виртуализации) ввода-вывода

ОС взаимодействует с устройствами ввода-вывода через их регистры (PIO/MMIO), интерфейс DMA (Direct Memory Access) и прерывания. Все эти способы взаимодействия моделируются внутри эмулятора QEMU, который выступает для гостевой ОС в качестве программы начального старта. При инициализации виртуальной машины QEMU генерирует для гостя PCI-дерево (Peripheral Component Interconnect) всех доступных устройств. Доступы гостя к регистрам устройств попадают в QEMU через перехваты. При необходимости QEMU может осуществлять гостевые DMA (поскольку гипервизору доступна вся гостевая физическая память), а также доставлять гостевые прерывания.

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

Метод паравиртуализации ввода-вывода (virtio)

Для уменьшения задержек эмуляции используются специальные виртуальные устройства, предназначенные для эффективной виртуализации, – virtio [4]. С их применением улучшение производительности по сравнению с полной виртуализацией устройств достигается за счет значительного снижения числа перехватов и гостевых прерываний. Интерфейс virtio реализуется рядом виртуальных устройств и соответствующих им драйверов, включая серийный порт, жесткий диск и сетевой адаптер. С целью улучшения пропускной способности сети также реализовано устройство Vhost-net, позволяющее обрабатывать перехваты в модулях ядра Linux KVM без выхода в QEMU. Поскольку физических устройств virtio не существует, операционная система, работающая с драйверами virtio, может быть только гостевой. Таким образом, гость неизбежно получает информацию о том, что он запущен внутри виртуальной машины, а значит, драйверы virtio можно считать элементами паравиртуализации гостя.

Метод прямого назначения устройства

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

Interrupts) с произвольным вектором. Для защиты от такого поведения гостя в проектах «Эльбрус» были проведены аппаратные доработки блока IOMMU (Input/Output Memory Management Unit).

По аналогии с блоком управления памятью MMU (Memory Management Unit) устройство IOMMU выполняет проход по таблице страниц для трансляции виртуальных адресов в физические. Но блок IOMMU, в отличие от MMU, не позволяет обрабатывать отказы страницы, поскольку устройства ввода-вывода рассчитывают на доступность DMAбуферов в любой момент времени. Во избежание отказов страниц при DMA реализация проброса устройства требует от гипервизора резидентирования всего гостевого физического адресного пространства в памяти. Это приводит к потере возможности применения стандартных оптимизаций физической памяти гостя.

Драйверами устройств традиционно заведует ядро ОС. Поскольку QEMU – это обычное пользовательское приложение, появилась необходимость в интерфейсе с ядром, который позволил бы реализовывать драйверы устройств в пространстве пользователя. Этот интерфейс – VFIO (Virtual Function I/O) – предоставляет пользовательским драйверам доступ к регистрам устройства, DMA и прерываниям. VFIO позволяет приложению QEMU создать и эмулировать виртуальное конфигурационное пространство PCI для пробрасываемого устройства, отображать регистры устройства гостю для доступа без перехватов, а также резервировать физическую память гостя и заполнять гипервизорную таблицу страниц IOMMU. Для поддержки метода прямого назначения устройства интерфейс VFIO был портирован на архитектуру «Эльбрус».

Аппаратная поддержка виртуализации ввода-вывода в микропроцессорах с архитектурой «Эльбрус»

Согласно [5, 6] для аппаратной поддержки прямого назначения устройства гостю необходимо обеспечить:

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

Трансляция DMA-обращений гостевого устройства обеспечивается блоком IOMMU, тогда как замаршрутизацию и доставку гостевых прерываний главным образом отвечает программируемый контроллер прерываний «Эльбрус» (EPIC), с промежуточной трансляцией прерываний в IOMMU [7]. При возникновении нештатной ситуации оба контроллера имеют возможность уведомления гипервизора об ошибке с помощью прерывания.

Рассмотрим подробнее механизм трансляции адресов DMA обращений, задача которого состоит в следующем:

1. 2. Изолировать устройства разных гостевых ОС. Организовать двухуровневую трансляцию адреса: из гостевого виртуального адреса (Guest Virtual Address, GVA) в гостевой физический адрес (Guest Physical Address, GPA), затем из GPA в физический адрес гипервизора (Host Physical Address, HPA).

Для выполнения первого требования необходимо использовать разные структуры трансляции для устройств разных гостей, то есть каждый гость должен иметь свой указатель на структуру трансляции. Данная возможность в процессоре «Эльбрус-16С» реализована через таблицу устройств DT (Device Table). Она расположена в физической памяти и для каждого устройства содержит номер гостя, указатель на структуру трансляции и различные права доступа. Таблица, которую формирует гипервизор, индексируется полным идентификатором PCIустройства (bus, device, function) и, таким образом, может содержать до 2 16 элементов. В блоке IOMMU реализован программно доступный регистр-указатель на DT, а также поддержка обращения к DT при трансляции адреса и кэширование элементов DT.

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

При поступлении запроса на трансляцию сначала выполняется поиск PA в IOTLB, при этом в качестве тэга поиска используется совокупность VA и PCI ID. В случае нахождения искомого VA для данного PCI ID выполняется чтение PA из IOTLB, происходит проверка прав доступа и формируется ответ из IOMMU. При отсутствии искомого VA для данного PCI ID выполняется поиск соответствующего элемента в таблице DT. Если элемент найден, то он считывается, при промахе – элемент DT считывается из оперативной памяти. Далее аналогичным

VA IOMMU

Трехстадийный конвейер трансляции адреса / Three-stage address translation pipeline

IOTLB

CR mmand co Device TW

Device TLB 1st level TW

TLU 2nd level TW

SL-TLU

Оперативная память / Main memory PA

Рисунок. Структурная схема блока IOMMU в составе процессора «Эльбрус-16С»: IOTLB (Input/ Output Translation Lookasidе Buffer) – кэш конечных трансляций; Device TW (Table Walker) – устройство обхода таблицы устройств; 1st Level TW – устройство обхода таблиц трансляции первого уровня; 2nd Level TW – устройство обхода таблиц трансляции второго уровня; Device TLB (Translation Lookasidе Buffer) – кэш-память таблицы устройств; TLU (Translation Lookasidе Unit) – кэшпамять таблиц трансляции первого уровня; SL-TLU – кэш-память таблиц трансляции второго уровня; CR – блок конфигурационных регистров; PA – физический адрес; VA – виртуальный адрес Figure. Structural diagram of the IOMMU as part of the Elbrus-16С processor: IOTLB (Input/Output Translation Lookaside Buffer) – final translations cache; Device TW (Table Walker) – unit for walking the device table; 1st Level TW – device for walking translation tables of the first level; 2nd Level TW – device for walking translation tables of the second level; Device TLB (Translation Lookaside Buffer) – device table cache; TLU (Translation Lookaside Unit) – cache memory of translation tables of the first level; SL-TLU – second-level translation table cache; CR – block of configuration registers; PA – physical address; VA – virtual address

образом выполняются поиск и чтение элементов таблиц трансляции первого и второго уровней.

На первом уровне выполняются трансляции GVA– GPA (при работе гостевого устройства по виртуальным адресам) и HVA – PA (при работе устройства под управлением гипервизора). Трансляция GPA – PA выполняется на втором уровне. Блок IOMMU поддерживает возможность работы гостевого устройства по GPA, в этом случае первый уровень трансляции пропускается. Режимы работы устройства задаются гипервизором в DT. Кроме того, на гипервизоре лежит обязанность по перехвату всех действий гостя со своими таблицами трансляции, так как гость не имеет прямого доступа к IOMMU.

Реализованный механизм трансляции адресов близок к варианту AMD [5], за исключением внутреннего содержимого структур трансляции. Также, в отличие от реализации AMD, позволяющей использовать в IOMMU произвольный размер страниц (кратный 4 Кб), на «Эльбрус» доступно только 3 фиксированных размера страниц (4 Кб, 2 Мб и 1 Гб), что позволило значительно упростить аппаратную реализацию. В отличие от реализации Intel [6] предложенная схема имеет одноуровневую таблицу устройств, в то время как Intel использует 2 уровня таблиц (Root Table и Context Table), что усложняет как аппаратную реализацию, так и процесс создания таблиц операционной системой. Кроме того, в отличие от Intel и AMD, описанная реализация IOMMU позволяет выполнять двухуровневую трансляцию без поддержки идентификаторов адресного пространства процесса (интерфейса PASID PCI Express) – это также позволило упростить аппаратную реализацию. Однако, из-за отсутствия поддержки PASID, при передаче одной виртуальной машине в пользование нескольких реальных устройств, трансляция их обращений будет выполняться по одинаковым таблицам, без изоляции указанных устройств друг от друга.

Выводы

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1.

2.

3.

4.

5.

6.

7. Bugnion E., Nieh J., TsafrirD. Hardware and Software Support for Virtualization (Synthesis Lectures on Computer Architecture). Morgan & Claypool Publishers, 2017, 208 p. Bellard F. QEMU, a Fast and Portable Dynamic Translator. In: Proceedings of the annual conference on USENIX Annual Technical Conference, 2005, pp. 41–46. KivityA., KamayY., LaorD, Lublin U., Liguori A. KVM: The Linux virtual machine monitor. In: Proceedings of the 2007 Ottawa Linux Symposium (OLS), 2007, pp. 225–230. Russell R. Virtio: towards a de-facto standard for virtual I/O devices. ACM SIGOPS Operating Systems Review, 2008, vol. 42, no. 5, pp. 95–103. AMD I/O Virtualization Technology (IOMMU) Specification Revision 2.0 [Электронный ресурс]. URL: http://developer.amd. com/wordpress/media/2012/10/48882.pdf (дата обращения: 22.04.2020). Intel Virtualization Technology for Directed I/O (VT-d) Architecture Specification [Электронный ресурс]. URL: https:// software.intel.com/content/dam/develop/public/us/en/documents/vt-directed-io-spec.pdf (дата обращения: 23.07.2020). Рыбаков С. А., Деменко Р. В. Виртуализация подсистемы прерываний микропроцессоров «Эльбрус» // Электроника: Наука, Технология, Бизнес. 2020. № 5. С. 68–72.

REFERENCES

1.

2.

3.

4.

5.

6.

7. Bugnion E., Nieh J., Tsafrir D. HardwareandSoftwareSupportforVirtualization (SynthesisLectureson ComputerArchitecture). Morgan & Claypool Publishers, 2017, 208 p. Bellard F. QEMU, a Fast and Portable Dynamic Translator. In: Proceedings of the annual conference on USENIX Annual Technical Conference, 2005, pp. 41–46. Kivity A., Kamay Y., Laor D, Lublin U., Liguori A. KVM: The Linux virtual machine monitor. In: Proceedings ofthe 2007 Ottawa Linux Symposium (OLS), 2007, pp. 225–230. Russell R. Virtio: towards a de-facto standard for virtual I/O devices. ACM SIGOPS Operating Systems Review, 2008, vol. 42, no. 5, pp. 95–103. AMD I/O Virtualization Technology (IOMMU) Specification Revision 2.0. Available at: http://developer.amd.com/wordpress/ media/2012/10/48882.pdf (accessed 20.07.2020). Intel Virtualization Technology for Directed I/O (VT-d) Architecture Specification. Available at: https://software.intel.com/ content/dam/develop/public/us/en/documents/vt-directed-io-spec.pdf (accessed 23.07.2020). Rybakov S. A., Demenko R. V. Virtualization of Elbrus microprocessor interrupt subsystem. Ehlektronika: Nauka, Tekhnologiya, Biznes, 2020, no. 5, pp. 68–72. (In Russian).

ИНФОРМАЦИЯ ОБ АВТОРАХ

Рыбаков Степан Андреевич, аспирант, ФГБОУ ВО «МИРЭА – Российский технологический университет», инженер-программист 1-й категории, АО «МЦСТ», 119334, Москва, ул. Вавилова, д. 24, тел.: +7 (499) 135-14-75, e-mail: Stepan.A.Rybakov@mcst.ru. Поляков Никита Юрьевич, старший инженер, АО «МЦСТ», 119334, Москва, ул. Вавилова, д. 24, тел.: +7 (499) 135-31 -08, e-mail: polyakov_n@mcst.ru.

AUTHORS

Stepan A. Rybakov, postgraduate student, MIREA – Russian Technological University, 1st category software engineer, MCST JSC, 24, ulitsa Vavilova, Moscow, 119334, Russia, tel.: +7 (499) 135-14-75, e-mail: Stepan.A.Rybakov@mcst.ru. Nikita Yu. Polyakov, senior engineer, MCST JSC, 24, ulitsa Vavilova, Moscow, 119334, Russia, tel.: +7 (499) 135-31 -08, e-mail: polyakov_n@mcst.ru.

Поступила 28.04.2020; принята к публикации 15.07.2020; опубликована онлайн 07.09.2020. Submitted 28.04.2020; revised 15.07.2020; published online 07.09.2020.