Сетевой адаптер Virtio-Net [2] - от устройства к драйверу

Это вторая часть разговора о Virtio-Net, в которой мы создадим каркас драйвера для работы с сетью в реальном режиме процессора CPU. Поняв суть, его можно будет портировать и в защищённый режим с плоской моделью вирт.памяти. Первая часть лежит здесь, и рекомендуется к прочтению.

Оглавление - часть(2):
1. Конфигурирование устройства
2. Настройка очередей приёма-передачи данных
3. Работа с прерываниями
4. Тестирование - отправка ARP-запроса на хост
5. Заключение

---

1. Конфигурирование адаптера Virtio-Net

Мы уже знаем, что порт из BAR[0] открывает доступ к регистрам в режиме Legacy, и теперь нужно согласовать способ взаимодействия с устройством на хосте. Схема здесь простая - девайс в первом регистре "DeviceFeatures" передаёт нашему драйверу список поддерживаемых им функций, а мы должны выбрать из этого списка только те, которые планируем программно у себя реализовать. Другими словами хост говорит "я умею это-это-это", а дров отвечает "мне нужно только это и это". Список представляет собой 32-битную маску (в режиме Modern 64-бита), в которой каждый бит определяет 1 фишку.


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

Обычно с толку сбивают биты TSO, GSO, UFO, ECN - рассмотрим их подробней.
Известно, что стандартный размер полезной нагрузки Payload в сетевом пакете равен 1500 байт, и если мы хотим передать за один раз например 4КБ данных, потребуется фрагментация сегмента на мелкие пакеты 1500+1500+1500. Параметром MTU хост сообщает макс.поддерживаемый им размер большого сегмента (обычно 9000 байт, Jumbo-Frames).

Так вот биты TSO и UFO выбирают, кто будет заниматься непосредственной фрагментацией больших пакетов - наш драйвер, или хост уже на своей стороне. Разумней переложить эту обязанность на хост, тогда мы сможем (без предварительных ласк) передавать за один раз пакеты размером до 64КБ. Биты подразумевают "TCP segmentation offload" и "UDP fragmentation offload", и при желании можно вообще не включать их, т.к. это просто оптимизация транспортного уровня L4 модели OSI.

В свою очередь хитрый бит GSO (generic) предлагает всем другую идею: "А давайте мы вообще не будем резать большой пакет на множество мелких, а делегируем эту задачу физ.адаптеру NIC". Ну и последний бит ECN выступает просто в роли навигатора, заранее сообщая о создавшихся на дороге пробках. В дефолте, когда входящих пакетов много и сеть перегружена, адаптер может тупо отбрасывать половину из них (дропать), а бит ECN предупреждает об этом - опция нам пока не нужна.


Вот как распределены биты в 32-битной маске "DeviceFeatures". Для удобства я разделит их на тетрады. Например мой хост передал мне значение 0x79BF8064, и теперь я могу сопоставить каждый из 8-ми разрядов этого значения, с соответствующей тетрадой списка. Так, младший разряд здесь 4h=0100, а значит взведён только бит(2) CTRL_OFFLOADS, и я могу отказаться от него, просто вернув в регистре порта "DriverFeatures" сброшенный этот бит. Следующий второй разряд 6h=0110, а это GSO+MAC, и т.д.


Вот несколько важных замечаний по Features:

1. Если вы случайно передадите не поддерживаемый хостом флаг, он его принудительно сбросит. Поэтому после того-как отправили своё значение, можно сразу считать его обратно, и сравнить с предыдущим. Это придаст уверенности, что скрытых ошибок нет и вы всё делаете правильно.

2. Если не нужны никакие навороты, можно запросить у хоста мин.конфигурацию в виде маски 0х00010020 - это установит всего два бита 5 и 16. После тестов базового функционала, позже поочерёдно добавим ещё и ещё битов оптимизации.

3. Помните, что чем проще ваш код, тем стабильнее он в работе. Правило Airplan-rule гласит: "двухмоторный самолёт по сравнению с одномоторным имеет вдвое больше шансов потерпеть крушение". Поэтому перекладывайте все трудоёмкие задачи на хост - у него толстая шея, и он способен решать серьёзные вопросы.


2. Настройка очередей приёма-передачи данных

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

Значит нам нужно создать 2 обязательные очереди VirtQueue - одну на приём данных от хоста (Receive, RX), а другую на передачу от драйвера (Transmit, TX). Чтобы хост мог их отличить, они имеют фиксированные номера: RX=0, а TX=1. На этапе конфигурации, физ.адрес этих очередей передаём хосту в регистрах порта - сначала выбор QUEUE_SELECT 0/1, а затем указатель в QUEUE_ADDRESS. Одна очередь занимает в памяти 3 (обязательно последовательные) страницы по 4КБ итого 12, и соответственно обе очереди RX-TX требуют 24КБ физической ОЗУ.

Очереди 0 и 1 представляют собой точную ксерокопию друг-друга, и отличаются всего одним битом "Write" в дескрипторах. После регистрации, они отображаются в разделяемую память Virtio, о которой мы говорили в первой части. Такая схема с отображаемй общей памятью позволяет эффективно обмениваться данными, т.к. по факту это просто проекция одного и того-же участка. Очередь включает в себя три таблицы: массив дескрипторов, кольцо Avail для драйвера, и кольцо Used для хоста.

2.1. Основная структура VIRTQ_DESC

Это массив 16-байтных дескрипторов, которые описывают адреса приёмо-передающих буферов в памяти. Кол-во дескрипторов в массиве определяет хост в регистре QUEUE_SIZE порта (см.выше), и как-правило их 256 штук. Таким образом, драйвер может иметь до 256 безпорядочно разбросанных по всей памяти буферов, а в каждый из дескрипторов мы будем записывать их адреса. Поскольку размер одного 16-байт, а всего их 256, весь массив занимает ровно 4КБ памяти.

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


Обратите внимание на флаг "Write" - именно этот единственный бит отличает очередь RX от TX. Когда мы передаём свой пакет хосту, нужно записать данные в буфер(TX), после чего сбросить этот бит в его дескрипторе, что значит доступ только на чтение ReadOnly. Но когда наоборот посылаем запрос и ждём ответ от хоста, нужно передать ему адрес приёмного буфера(RX), и чтобы хост смог записать в него, взводим флаг Write. Таким образом, буфер может иметь или атрибут R, или W, но не оба сразу R/W.

В свою очередь бит "Next" объединяет несколько дескрипторов так, что можно собрать (используемые в абсолютно всех пакетах передачи) заголовки Ethernet и прочие в один постоянный буфер с фиксированным размером, а полезные данные Payload уже во-второй буфер. Теперь, когда нужно передать пакет хосту, мы берём буфер с готовым заголовком, и через поле Next в дескрипторе добавляем к нему буфер пайлоада. Обнаружив такую цепочку, хост сам соберёт цельный пакет из двух фрагментов.

2.2. Структура VIRTQ_AVAIL - кольцевая очередь доступных дескрипторов.

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


• flags - управляет прерываниями, которые лучше не отключать (нужно сбросить в нуль).

• index - это общий счётчик индексов, которые мы передали хосту. При каждой отправке новой порции данных, драйвер должен увеличивать его на 1, и никогда не сбрасывать в нуль. Хост сравнивает это значение со своим внутренним счётчиком, чтобы понять, появились новые пакеты для обработки, или нет. При достижении 16-битного значения 65.535 происходит переполнение, счётчик заворачивается в кольцо, и автоматически начинает отсчёт заново с нуля.

• avail_ring - собственно массив с индексами используемых дескрипторов. Кол-во индексов в цепочке совпадает с кол-вом дескрипторов, т.е. тоже 256 штук. Когда на этапе инициализации устройства мы обнуляем всю выделенную для очередей память, это сбрасывает в начальное состояние поле Index=0, и весь массив Ring.

Теперь приём/передача данных происходит по такому сценарию:


Это означает, что мы должны последовательно использовать буквально все элементы массива avail_ring, от нуля и до последнего 255, хотя 255 это не константа, а значение регистра QUEUE_SIZE порта Virtio-Net. Важно понять, что поле index мы увеличиваем на 1 для того, чтобы в следующий раз точно определить позицию очередного элемента в длином массиве.

Но бесконтрольный +1 рано или поздно приведёт к тому, что index с макс.значением 65.535 выйдет за границу avail_ring[0..255]. Это приведёт к катастрофе, поэтому драйвер использует ограничение: avail_ring[x] = index % queue_size. То есть мы используем не чистый индекс, а его значение по модулю queue_size (остаток от деления на 256). Как результат, поле index будет продолжать отсчёт до 65.535 для хоста, а внутри драйвера получим замкнутый круг avail_ring[0..255 -> 0..255]. Собственно поэтому VirtQueue и называют кольцевой очередью "Ring", которую можно сравнить с конвейером на заводе.

2.3. Структура VIRTQ_USED - очередь обработанных дескрипторов.

Ну и последняя таблица - это used_ring. Как было сказано выше, драйвер не должен ничего записывать в неё, а только считывать элементы кольца. Как только хост обработает наш буфер (прочитает или запишет в него), в структуру Used он сохраняет отчёт о проделанной работе в виде индекса обработанного дескриптора, и размера данных в буфере. Поле len в каждом элементе кольца имеет смысл только для очереди приёма(RX) - это единственный способ узнать размер пакета, который хост отправил драйверу (иначе мы не сможем вытащить из него пайлоад). Таким образом баланс поддерживают 2 кольца - Avail занимает буферы, а Used освобождает.


На рис.ниже схема взаимосвязи всех структур в одной очереди VirtQueue. Вторая очередь полностью идентична, только отличается флагами RX-TX в дескрипторах. Кроме того, все эти три структуры должны располагаться в памяти строго в определённом порядке - сначала таблица дескрипторов 4КБ, за ней кольцо Avail с дополнением до 4КБ, и в самом конце уже кольцо Used. Дело в том, что при регистрации очереди мы передаём хосту только адрес таблицы дексрипторов (как указатель на голову), а оставшиеся две структуры хост уже находит сам придерживаясь спецификации. Если поменять Avail и Used местами - вся конструкция рухнет.


Инициатором в операциях обмена всегда выступает драйвер, поскольку при любых обстоятельствах хосту требуется буфер в памяти, а его может предоставить только драйвер через свою структуру Avail. В результате цепочка будет: Avail -> Desc -> Used. Здесь драйвер использует всего 4 буфера из возможных 256, при этом буфер(0) задействуется повторно уже после того, как хост завершит операцию(1), переместит дескриптор в пул свободных Used, и пошлёт прерывание драйверу.



Вот пример регистрации очередей, который состоит из 4-х пунктов, и после каждого, мы должны в регистре DEVICE_STATUS отправлять хосту отчёт, что именно сделали на текущий момент. Регистр доступен не только на запись, но и на чтение - так мы сможем проверить, принял хост наш статус, или в процессе настройки произошла ошибка. Если хост обнаружит ошибку, в регистре DEVICE_STATUS он вернёт значение, которое мы отправили ему в последний раз.

Обратите внимание, что статус - это двоичная маска, а потому нельзя менять уже установленные в ней биты. То есть правильно будет считать предыдущее значение, логикой OR прибавить к нему новое, и отправить хосту уже их сумму. На заключительном этапе, статус должен быть равен 0Fh, т.е. выставлены в единицу все 4 бита:


3. Обработка прерываний

Прерывания сигнализируют о каком-либо событии. В контексте VirtioNet только хост может отправлять прерывания драйверу в регистре ISR_STATUS после записи в кольцо used_ring. Однако и драйвер со-своей стороны тоже посылает маяки хосту после подготовки дескрипторов и записи в avail_ring, только делает он это уже через оповещения в регистре QUEUE_NOTIFY. Регистр статуса может принимать сл.значения: 0=чисто, 1=прерывание от очереди, 2=изменилась конфигурация.

После того-как драйвер получит сигнал, он должен запустить свою процедуру обслуживания "Interrupt Service Routine" ISR, и здесь всплывает проблема идентификации события, т.е. определения причины, по которой хост отправил нам прерывание. Ситуацию усугубляет и то, что очереди у нас две RX-TX, а регистр ISR_STATUS один - вот и разберись, из какой именно очереди к нам постучались. Когда трафик течёт непрерывным потоком (что типично для сетевых адаптеров), нужна быстрая реакция на события, иначе получим затор и потерю пакетов.

В конструкции любого из внешних устройств предусмотрена линия IRQ (Interrupt Request, запрос на прерывание), по которой логика девайса могла-бы отправлять свои сигналы контроллеру PIC на мат.плате. Каждой такой линии биос назначает свой номер и сохраняет его в поле "IRQ-Line" конфиг-пространства. Моему VirtioNet биос выделил IRQ-11, и теперь используя формулу ниже я смогу узнать вектор INT, куда биос поместил ISR моего прерывания - как видим это INT-73h.



Биос не знает как нужно работать с внешним девайсом, поэтому вместо реального обработчика прописывает тупо заглушку, которая состоит всего из одной инструкции iret (сразу на выход). Теперь задача перехватить вектор 73h в системной таблице IVT (Interrupt Vector Table), чтобы он указывал на мою процедуру ISR - вот пример:


3.1. Polling обработка

Мало обратить IRQ в INT и перехватить вектор прерывания, так внутри обработчика "IsrHandler" теперь нужно определить, от какой из очередей RX-TX пришёл сигнал. Когда вектор 1, а условий 2 (как в нашем случае), по любому требуется циклический опрос обоих очередь, или т.н. "Polling". Другими словами отправили хосту запрос + чистый буфер, и смотрим, вернулось что-нибудь в него или нет. При таких раскладах отпадает надобность и в самих прерываниях! Это самый простой и удобный вариант, который используется повместно, а не только в адаптерах сети.


3.2. Обработка с использованием MSI-X

Когда разработчики поняли проблему, на смену традиционным INTx всего с одним разделяемым вектором, в Virtio пришёл современный механизм "Message Signaled Interrupt" MSI-X, который поддерживает уже 2048 векторов на одно прерывание. Это даёт нам возможность внутри одной линии закодировать 2048 разных сообщений, и на каждое повесить свою процедуру ISR. Соглассно спеке, MSI-X рассчитан на работу Virtio в современном режиме Modern, а у нас здесь разговор про Legacy, в котором используется линия INTx с одним вектором. Всё это сложно и требует отдельного разговора, т.ч. кому интересно - можете заглянуть в спецификацию.

4. Формат пакетов

Ну и под занавес рассмотрим, что-да-как передавать.
Известно, что в любом (передаваемом по сети) пакете, помимо полезных данных Payload всегда имеются заголовки, которые зависят от протокола передачи. Так вот устройства VirtioNet вставляют в самое начало кадра свой заголовок размером 10-байт, а если в Features согласован бит(15) "VIRTIO_NET_F_MRG_RXBUF", то добавляются ещё 2-байта. Вот формат этого заголовка, и в случае несогласования оптимизации GSO, можно просто забить его нулями.



В своей демке я посылаю ARP-запрос хосту, а он должен вернуть мне свой МАС. Обмен такого рода подтвердит работоспособность 2-стороннего обмена в локальной сети. Вот структура самого запроса, который я прописываю в свой буфер передачи TX, а он мне отвечает в заранее подготовленный для этих целей мною буфер RX.


Консольное окно не позволяет вывести приёмный буфер на экран, но в него можно заглянуть командой xp /100hx <адрес буфа>. Здесь видно, что в дескрипторе очереди TX я передаю адрес буфера 0x00127000 и его размер 0x34=52 байта, а хост мне возвращает в очереди RX used_ring размер отправленных им данных 0x4A=74 байта.



5. Заключение

Программирование физических и виртуальных устройств методом "проб и ошибок" довольно интересно, т.к. узнаёшь много нового. Полученные знания можно будет использовать в разных сферах, а не только в данном контексте. Однако это весело, только когда есть офицальная спека от производителя, иначе приходится сутками реверсить чужой код, и хорошо, если в итоге что-то получится. В скрепке найдёте весь исходный код драйвера VirtioNet на ассемблере fasm, а так-же готовый img-образ флопика для тестов в эмуляторе QEMU. Всем удачи, пока!