Драйвер null для устройств amd iommu что это

Драйвер null для устройств amd iommu что это

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

Конфигурация PC:
CPU: Intel Core i5-3450 3.1GHz
MB: ASRock LGA1155 P67 Pro3
ОЗУ: 2 x DIMM DDR3 4096MB PC12800 1600MHz
HDD/SSD: SSD Sandisk Extreme II [SDSSDXP-240G-G25] 1500Gb Seagate Barracuda 7200.11 ST31500341AS (7200 rpm, 32Mb, SATA-II)
Video: GIGABYTE GV-N760OC-2GD, 2Гб, GDDR5, OC, PCI-E 3.0
Sound: ASUS Xonar Essence STX
АC: B&W DM-305, Sennheiser HD 595
Корпус: ZALMAN Z5 U3
БП: Thermaltake Toughpower 700W
Cooler: Zalman CNPS10X Optima
Модем: TP-Link TD-W8951ND
Монитор: NEC MultiSync 20WGX2 Pro
OS: Windows 7 x64 Ultimate

S_Snake, широкое распространение гипервизоров виртуальных машин привело к включению поддержки IOMMU в «гостевые» ОС, такие, как Windows (API ядра Windows всегда поддерживал данную функцию, хотя обычно данная поддержка не реализовывалась).

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

Источник

Не хочет устанавливаться пакет видеодрайверов AMD

Приветствую. В общем на скриншоте всё понятно.

Ставил в таком порядке:
AMD Catalyst RAIDXpert Utility
AMD Catalyst SB SATA AHCI
перезагрузка
AMD Catalyst 15.10Beta 64Bit Win7
И выдаёт про «..установочный пакет. «

Старые дрова сносил DDU. Чистил ccleaner-ом.
Windows 7×64, MSI R7 260x OC. Остальные параметры бессмысленны.
Чего же он хочет?

Не хочет устанавливаться
Ребят помогите.У меня такая проблема с установкой вин7 загружаю диск и далее все идет так: удалено.

Не хочет устанавливаться
Пытаюсь установить ubuntu. С полным удалением диска. Там что бы там была только ubuntu. Но во время.

Слетела хр, не хочет устанавливаться
Здравствуйте, уважаемые форумчане. Возникла такая проблема(у друга). Стояла виндовс хр, но.

8.1 Не хочет устанавливаться с DVD+R
Проблема в следующем: Нужно переустановить систему Seven x64 на Windows 8.1 1)Скачал образ.

AMD Radeon R7 200 Series
Advanced Micro Devices, Inc.

0x6658
0x1002
0x2938
0x1462
0x030000
0x00

Advanced Micro Devices, Inc.

0xaac0
0x1002
0xaac0
0x1462
0x040300
0x00

Advanced Micro Devices, Inc.

0x5a1c
0x1002
0x0000
0x0000
0x060400
0x00

ATI Integrated SATA Support
Advanced Micro Devices, Inc.

0x4391
0x1002
0x4391
0x1849
0x010601
0x40

ATI Integrated SMBus Support
Advanced Micro Devices, Inc.

0x4385
0x1002
0x4385
0x1849
0x0c0500
0x42

ATI Integrated SATA Support
Advanced Micro Devices, Inc.

0x439c
0x1002
0x439c
0x1849
0x01018a
0x40

Advanced Micro Devices, Inc.

0x4384
0x1002
0x0000
0x0000
0x060401
0x40

Advanced Micro Devices, Inc.

0x43a0
0x1002
0x0000
0x0000
0x060400
0x00

Advanced Micro Devices, Inc.

0x43a3
0x1002
0x0000
0x0000
0x060400
0x00

Advanced Micro Devices, Inc.

0x1600
0x1022
0x0000
0x0000
0x060000
0x00

Advanced Micro Devices, Inc.

0x1601
0x1022
0x0000
0x0000
0x060000
0x00

Advanced Micro Devices, Inc.

0x1602
0x1022
0x0000
0x0000
0x060000
0x00

Advanced Micro Devices, Inc.

0x1603
0x1022
0x0000
0x0000
0x060000
0x00

Advanced Micro Devices, Inc.

0x1604
0x1022
0x0000
0x0000
0x060000
0x00

Advanced Micro Devices, Inc.

0x1605
0x1022
0x0000
0x0000
0x060000
0x00

Диспетчер установки AMD Catalyst

8.0.916.0
20

Драйвер NULL для устройств AMD IOMMU

1.0.3.0022
1

Драйвер AHCI-массива AMD SATA

1.2.001.0402
1

Драйвер фильтра AMD USB

2.0.10.287
1

Диспетчер установки AMD Catalyst
Succeed
8.0.916.0
20

Драйвер дисплея AMD
Succeed
15.201.1151.1007
90

Аудиодрайвер HDMI
Succeed
7.12.0.7723
1

AMD Steady Video Plug-In
Fail
2.08.0000
1

AMD перекодировка при перетаскивании мышью
Succeed
2.00.0000
1

AMD Catalyst Control Center
Succeed
2015.1103.1712.30903
150

ACP Application
Succeed
2015.1103.1654.11
1

Другие обнаруженные устройства
Сообщения об ошибках
Имя
Изготовитель
Тип набора микросхем
Идент-тор устройства
Другое оборудование
Загружаемые пакеты
Оп-ция вып. успеш.
Ошибка
Идент-тор поставщика
Код класса
Идентификатор редакции
Идентификатор подсистемы
Идентификатор поставщика подсистемы
Диспетчер установки Catalyst™
Отчет об установке
Конечное состояние:
Версия элемента:
Размер:
Мбайт

Установка приложения: исходный установочный пакет не найден

Источник

Как IOMMU работает для связи ЦП и периферийных устройств

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

Где находится IOMMU?

Как видно на схеме выше, периферийные устройства подключены к южному мосту или южному мосту, который, в свою очередь, подключен к северному мосту, который является концентратором, с которым, в основном, обмениваются данными интерфейс оперативной памяти и процессора. каждый. Что ж, IOMMU расположен внутри южного моста, где сосредоточены все интерфейсы ввода-вывода, такие как USB, PCI Express, SATA и т. Д.

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

Таким образом, IOMMU действует как MMU, но для периферийных устройств ввода-вывода.

В чем его полезность?

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

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

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

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

Использование IOMMU в виртуализированных системах

IOMMU обеспечивает безопасный доступ к физическим устройствам в виртуализированных средах посредством того, что мы называем сквозной передачей устройств. Тандем между MMU и IOMMU позволяет устройствам, подключенным к ПК, появляться в пространстве виртуальной памяти, которое выполняет функцию физической памяти для виртуальной среды, которая работает в данный момент.

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

Источник

Использование DPDK для обеспечения высокой производительности прикладных решений (часть 0)

Сейчас вряд ли кого-то удивить использованием epoll()/kqueue() в поллерах событий. Для решения проблемы C10K cуществует довольно много разнообразных решений (libevent/libev/libuv), с разной производительностью и довольно высокими накладными расходами. В статье рассматривается использование DPDK для решения задачи обработки 10 миллионов соединений (С10M), и достижение максимального прироста производительности при обработке сетевых запросов в распространённых прикладных решениях. Главной особенностью подобной задачи является делегирование ответственности обработки трафика с ядра ОС в пользовательское пространство (userspace), точный контроль обработки прерываний и каналов DMA, использование VFIO, и много других не очень понятных слов. В качестве целевого прикладного окружения было выбрано Java Netty с использованием Disruptor паттерна и offheap кэширования.

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

В статье очень детально рассмотрены вопросы установки, настройки, использования, отладки, профилирования и разворачивания DPDK для построения высокопроизводительных решений.

netmap

Основной задачей при разработке netmap являлась разработка простого в использовании решения, по этому предоставляется наиболее распространённый синхронный интерфейс select(), что позволяет значительно упростить портирование существующих решений. С точки зрения гибкости и абстрагирования железа netmap‘у явно не хватает функционала. Тем не менее это наиболее доступное и распространённое решение (даже под богомерзким Windows). Сейчас netmap поставляется прямо в составе freebsd и есть довольно неплохая поддержка для стороны libpcap. Поддерживается силами Luigi Rizzo и Alessio Faina, является проектом Пизанского Университета. Естественно ни о какой коммерческой поддержке речи не идёт, хотя и сделано так, что отвалиться нечему.

pf_ring

pf_ring появился как средство «разгона» pcap’a, и так уж исторически сложилось что на момент разработки не было готовых к использованию, стабильных решений. Явных преимуществ перед тем же netmap’ом у него не много, но есть поддержка IOMMU в проприетарной ZC версии. Сам по себе продукт издавна не отличался высокой производительностью или качеством, является не более чем средством сбора и анализа pcap дампов и не предназначался для обработки трафика в пользовательских приложениях. Главной особенностью pf_ring‘a ZC является полная независимость от существующих драйверов сетевых интерфейсов.

OpenOnload

OpenOnload узкоспециализированный высокопроизводительный, древний сетевой стек от SolarFlare. Они занимаются выпуском брэндированных 10/40GbE адаптеров для HP, IBM, Lenovo, Stratus. К сожалению сам OpenOnload поддерживает не все существующие адаптеры SolarFlare. Главной особенностью OpenOnload является полная замена API BSD cокетов, в том числе и epoll() механизма. Да, теперь ваш nginx может одолеть планку в 38Gbit без каких либо сторонних модификаций. SolarFlare предоставляет коммерческую поддержку и у неё очень много респектабельных клиентов. Я не знаю как обстоят дела с виртуализацией в OpenOnload, но если вы сидите на контейнерах за nginx балансером — это самое простое и доступное решение, без лишних заморочек. Покупайте, пользуйтесь, молитесь что б не отвалилось, и можете дальше не читать.

Другие

Есть ещё решения Napatech, но, на сколько мне известно, у них там просто библиотека со своим API, без вундервафель как у SolarFlare, по этому их решения менее распространены.

Естественно я рассмотрел не все существующие решения — я просто не мог со всем столкнуться, но я не думаю что они могут сильно отличаться от того что описано выше.

Исторически так сложилось, что наиболее распространёнными адаптерами для работы c 10/40GbE являются адаптеры Intel обслуживаемые e1000 igb ixgbe i40e драйверами. По этому они являются частыми целевыми адаптерами для высокопроизводительных средств обработки трафика. Так было с Netmap и pf_ring, разработчики которых являются возможно хорошими знакомыми. Было бы странно если бы Intel не занялась разработкой собственного средства обработки трафика — ним является DPDK.

DPDK это OpenSource проект Intel‘a, на основе которого были построены целые конторы (6WIND) и для которого производители изредка предоставляют драйвера, например Mellanox. Естественно, коммерческая поддержка решений на его основе просто замечательная, её предоставляет довольно большое количество вендоров (6WIND, Aricent, ALTEN Calsoft Labs, Advantech, Brocade, Radisys,Tieto, Wind River, Lanner, Mobica)

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

Список поддерживаемых драйверов и карт

Архитектура DPDK

* это он у меня в голове так фунциклирует, реальность может чуть отличаться

Kernel Network Interface (KNI) — это специализированный драйвер который позволяет взаимодействовать с сетевым API ядра, выполнять ioctl вызовы к портам интерфейсов которые работают с DPDK, использовать распространённые утилиты (ethtool, ifconfig, tcpdump) для управления ими.

Как видите, у DPDK, по сравнению с другими решениями netmap’ом, хренова тьма много плюшек для реализации SDN’ов, которые так и манят на тёмную сторону аппаратного искусства.

Требования и тонкая настройка целевой системы

Переведены и дополнены основные рекомендации официальной документации.
Не затронут вопрос настройки гипервизоров XEN и VMware для работы с DPDK.

Общие

Если вы ставите ваш DPDK под Intel Communications Chipset 89xx, то вам сюда.
Для сборки нужен coreutils, gcc, заголовки ядра, заголовки glibc.
Вроде поддерживается clang, и есть поддержка Intel‘овского icc.
Для запуска вспомогательных скриптов — Python 2.6/2.7

Ядро Linux должно быть собрано с поддержкой UIO и мониторингом адресных пространств процессов, это параметры ядра:
CONFIG_UIO
CONFIG_UIO_PDRV
CONFIG_UIO_PDRV_GENIRQ
CONFIG_UIO_PCI_GENERIC
и
CONFIG_PROC_PAGE_MONITOR

Хочу обратить внимание на то что в grsecurity параметр PROC_PAGE_MONITOR считается слишком уж информативным — помогает в эксплуатировании уязвимостей ядра и в обходе ASLR.

Для организации периодических прерываний высокой точности нужен HPET таймер.

Можно глянуть наличиеПойти включить в BIOS’e

И собрать ядро с включенным CONFIG_HPET и CONFIG_HPET_MMAP.

По умолчанию поддержка HPET выключена в самом DPDK, по этому нужно её включить выставив флаг CONFIG_RTE_LIBEAL_USE_HPET вручную в файле config/common_linuxapp.

Изоляция ядер

Для широкораспространённого grub’a это параметр GRUB_CMDLINE_LINUX_DEFAULT в конфиге /etc/default/grub.

Hugepages

Это выделит 1024 страницы по 2МБайт’a.

Для выделения четырёх страниц по гигабайту:

default_hugepagesz=1G hugepagesz=1G hugepages=4

Но нужна соответствующая поддеркжа — флаг процессора pdpe1gb в /proc/cpuinfo.

Для 64-разрядных приложений использование 1ГБайт’ных страниц является предпочтительным.

Для получения информации о распределении страниц между ядрами в NUMA системе, можно использовать следующую команду

Более подробно об управлением политикой выделения и освобождения больших страниц в NUMA системах можно почитать в официальной документации.

Для поддержки больших страниц нужно собрать ядро с параметром CONFIG_HUGETLBFS

Управления выделенными областями памяти для больших страниц осуществлеятся механизмом Transparent Hugepage, который выполняет дефрагментацию в отдельном потоке ядра khugepaged. Для его поддержки нужно собирать с параметром CONFIG_TRANSPARENT_HUGEPAGE и политик CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS либо CONFIG_TRANSPARENT_HUGEPAGE_MADVISE.

Этот механизм остаётся актуальным даже в случае выделения больших страниц во время загрузки ОС, так как тем не менее остаётся вероятность отсутствия возможности выделения непрерывных областей памяти для страниц в 2МБайт’а, по различным причинам.

Есть блокбастер о NUMA и памяти от адептов Intel‘a.
Есть небольшая статья о использовании больших страниц от Rad Hat.

После настройки и выделения страниц нужно примонтировать их, для этого нужно добавить в /etc/fstab соответствующую точку монтирования

Для 1Гбайт’овых страниц размер страницы нужно указать дополнительным параметром

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

Кстати, в Power8 размер больших страниц составляет 16МБайт и 16ГБайт что, как по мне, немного перебор.

Менеджмент энергопотребления

В DPDK уже есть средства по управлению частотами процессора, так что бы стандартные политики «не совали палки в колёса».
Для их использования нужно включить SpeedStep и C3 С6.

У вас в BIOS путь к настройкам мог бы выглядеть вот так

Аdvanced->Processor Configuration->Enhanced Intel SpeedStep Tech
Advanced->Processor Configuration->Processor C3 Advanced->Processor Configuration-> Processor C6

В приложении l3fwd-power представлен пример L3 свитча с использованием функций управления энергопотреблением.

Права доступа

Понятное дело что выполнять приложение с root’овыми правами доступа очень небезопасно.
Целесообразно использовать ACL для создания прав доступа отдельной пользовательской группы

Что добавит полный доступ для группы пользователей dpdk для используемых ресурсов и устройства uio0.

Прошивка

Для 40GbE cетевых адаптеров обработка мелких пакетов является довольно сложной задачей, и от прошивки до прошивки Intel внедряет дополнительные оптимизации. Поддержка прошивок серии FLV3E реализована в DPDK 2.2-rc2, но пока наиболее оптимальной является версия 4.2.6. Вы можете обратиться в поддержку вендоров или напрямую к Intel‘у для обновления, либо обновить самостоятельно.

Расширенные метки, размер запроса и дескрипторов чтения в PCIe устройствах

Параметры PCIe шины extended_tag и max_read_request_size значительно влияют на скорость обработки мелких пакетов — порядка 100Байт 40GbE адаптерами. В некоторых версиях BIOS их можно установить вручную — 125 Байт и «1» соответственно, для 100 Байтных пакетов.

Значения можно выставить в конфиге config/common_linuxapp при сборке DPDK, с помощью следующих параметров:

CONFIG_RTE_PCI_CONFIG
CONFIG_RTE_PCI_EXTENDED_TAG
CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE

Либо с помощью setpci lspci команд.

Вот в чём разница между MAX_REQUEST и MAX_PAYLOAD параметрами для PCIe устройств, но в конфигах есть только MAX_REQUEST.

Для i40e драйвера имеет смысл уменьшить размер дескрипторов чтения до 16 Байт, выполнить это можно установкой следующего параметра: CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC в config/common_linuxapp или в config/common_bsdapp соответственно.
Также можно указать минимальный интервал между обработкой прерываний записи CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL в зависимости от существующих приоритетов: максимальной пропускной способности или попакетным задержкам.

Также подобные параметры есть для драйвера Mellanox mlx4.

CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N
CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE
CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE
CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS

Которые наверняка как-то влияют на производительность.

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

IOMMU для работы с Intel VT-d

Что приводит к корректной трансляции адресов DMA (DMA remapping). Поддержка IOMMU для целевого сетевого адаптера в гипервизоре выключается. Сам по себе IOMMU довольно расточителен для высокопроизводительных сетевых интерфейсов. В DPDK реализован маппинг «один к одному», по этому полная поддержка IOMMU не требуется, хоть это и ещё одна брешь в безопасности.

Если при сборке ядра установлен флаг INTEL_IOMMU_DEFAULT_ON то должен использоваться параметр загрузки

Что гарантирует корректную инициализацию Intel IOMMU.

Хочу обратить внимание что использование UIO (uio_pci_generic, igb_uio) является опциональным для ядер поддерживающих VFIO (vfio-pci), с помощью которых реализованы функции взаимодействия с целевыми сетевыми интерфейсами.

igb_uio нужен в случае отсутствия поддержки некоторых прерываний и/или виртуальных функций целевыми сетевыми адаптерами, иначе можно спокойно использовать uio_pci_generic.

Не смотря на то что iommu=pt параметр является обязательным для igb_uio драйвера, vfio-pci драйвер корректно функционирует как с параметром iommu=pt так и с iommu=on.

Сам по себе VFIO функциклирует довольно упорото странно, в связи с особенностями работы IOMMU групп: некоторые устройства требуют что бы все их порты были привязаны (binded) под VFIO, другим нужны только некоторые, третим вообще не нужно ничего привязывать.

Если ваше устройство находится за PCI-to-PCI мостом, то драйвер моста будет входить в ту же IOMMU группу что и целевой адаптер, по этому драйвер моста нужно выгрузить — что бы VFIO могло подхватить устройства за мостом.

Проверить расположение существующих устройств и используемые драйвера можно скриптом:

Также можно явно привязать драйвера к конкретным сетевым устройствам

Установка

Берём исходники и собираем так как описано далее.
Сам DPDK поставляется с набором приложений-примеров, на которых можно обкатать корректность настройки системы.

Настройка DPDK, как уже было сказано выше, производится посредством установки параметров в файлах config/common_linuxapp и config/common_bsdapp. Стандартные значения платформозависимых параметров хранятся в файлах config/defconfig_*.

Сначала производится применение шаблона конфигурации, создаётся папка build со всей живностью и таргетами:

В DPDK 2.2 доступны следующие целевые окружения (у меня)

ivshmem — это механизм QEMU который вроде как позволяет делиться областью памяти между несколькими гостевыми виртуальными машинами без копирования, посредством общего специализированного устройства. Хотя копировать в разделяемую (shared) память нужно в случае коммуникации между гостевыми ОС, правда это не случай DPDK. Сам по себе ivshmem реализован довольно просто.

Предназначение остальных шаблонов конфигурации должно быть очевидным, иначе зачем вы вообще это читаете?

Кроме шаблона конфигурации есть другие опциональные параметры

Далее просто старый-добрый

Список целей для make довольно банален

Для работы нужно загрузить UIO модули
или

Если используется VFIO

Если используется KNI

Сборка и запуск примеров

Для проверки номерации ядер в системе можно использовать команду lstopo из пакета hwloc.

Для сборки и запуска Hello World

Таким образом приложение выполнится на четырех ядрах, c учётом что установлено 2 планки памяти.
И получим мы 5 hello world’ов с разных ядер.

Проблема курицы, яйца и птеродактиля

Я выбрал Java как целевую платформу из-за относительно высокой производительности виртуальной машины и возможности внедрения дополнительных механизмов менеджмента памяти. Вопрос как распределить ответственность: где выделять память, где управлять потоками, как выполнять планировку задач и что особенного в механизмах DPDK — довольно сложен и двузначен. Пришлось незаурядно поколупаться в исходниках DPDK, Netty и самого OpenJDK. В итоге были разработаны специализированные версии компонентов netty с очень глубокой интеграцией DPDK.

Источник