Iommu controller что это - TurboComputer.ru
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд (пока оценок нет)
Загрузка...

Iommu controller что это

Опция BIOS Virtualization – как включить виртуализацию в BIOS

Опция Virtualization Technology. Включение данной опции включает технологию аппаратной виртуализации, основанной на специальной процессорной архитектуре. В отличие от программной виртуализации, с помощью данной техники возможно использование изолированных гостевых систем (виртуальных машинах – VMware, Virtual PC и тд.), управляемых гипервизором напрямую. Гостевая система не зависит от архитектуры хостовой платформы и реализации платформы виртуализации.

На работу программ пользователя в стандартной операционной системе данная опция практически не влияет.

Значения опции:

  • Enabled,
  • Disabled

Опция также может иметь другие названия:

  • Virtualization Technology
  • Vanderpool Technology
  • VT Technology
  • Virtualization

Примечание 1.Аппаратная виртуализация виртуализация с поддержкой специальной процессорной архитектуры. Аппаратная виртуализация обеспечивает производительность, сравнимую с производительностью невиртуализованной машины, что дает виртуализации возможность практического использования и влечет её широкое распространение. Наиболее распространены технологии виртуализации Intel-VT и AMD-V.

  1. В Intel VT (Intel Virtualization Technology) реализована виртуализация режима реальной адресации (режим совместимости с 8086). Соответствующая аппаратная виртуализация ввода-вывода — VT-d. Часто обозначается аббревиатурой VMX (Virtual Machine eXtension). Кодовое название — Vanderpool.
  2. AMD-V часто обозначается аббревиатурой SVM (Secure Virtual Machines). Кодовое название — Pacifica. Соответствующая технология виртуализации ввода-вывода — IOMMU. AMD-V проще и эффективнее, чем Intel VT. Поддержка AMD-V появилась в Xen 3.3.

Intel VT (Intel Virtualization Technology) – intel virtualization technology что это?

VT-x 13 ноября 2005 года Intel выпустила две модели Pentium 4 (модели 662 и 672), которые стали первыми процессорами, поддерживающими VT-x (“Vanderpool”). VT-x представляет собой технологию виртуализации Intel режима реальной адресации на платформе x86 – VMX (Virtual Machine eXtension).

Реализована виртуализация режима реальной адресации (режим совместимости с 8086).

VT-d (Virtualization technology for directed I/O) — технология аппаратной виртуализации ввода-вывода , созданная корпорацией Intel в дополнение к её технологии виртуализации вычислений VT-x. Виртуализация ввода-вывода позволяет пробрасывать (pass-through) устройства на шине PCI (и более современных подобных шинах) в гостевую ОС, таким образом, что она может работать с ним с помощью своих штатных средств. Чтобы такое было возможно, в логических схемах системной платы используется специальное устройство управления памятью ввода-вывода (IOMMU), работающее аналогично MMU центрального процессора, используя таблицы страниц и специальную таблицу отображения DMA (DMA remapping table — DMAR), которую гипервизор получает от BIOS через ACPI. Отображение DMA необходимо, поскольку гипервизор ничего не знает о специфике работы устройства с памятью по физическим адресам, которые известны лишь драйверу. С помощью DMAR он создает таблицы отображения таким образом, что драйвер гостевой ОС видит виртуальные адреса IOMMU аналогично тому, как бы он видел физические без него и гипервизора.

Intel Virtualization Technology for Directed I/O (VT-d) — это следующий важный шаг на пути к всеобъемлющей аппаратной поддержке виртуализации платформ на базе Intel. VT-d расширяет возможности технологии Virtualization Technology (VT), существующей в IA-32 (VT-x) и Itanium (VT-i), и добавляет поддержку виртуализации новых устройств ввода-вывода. Ознакомиться подробнее с технической стороной вопроса можно здесь https://ru.wikipedia.org/wiki/

Программа Setup BIOS фирмы AWARD Software International Inc на системных платах GIGABYTE TECHNOLOGY

Название данной опции у данного производителя в данной версии BIOS:

Virtualization значение по умолчанию [Disabled]

Hardware assisted VirtuaIization Technology which help improve performance of system running VirtuaI Machine Softwares.

Virtual Machine allows multiple OS on one conputer simultaneously.

Оборудование для помощи VirtuaIization – технология которая помогает повысить производительность системы, работающей на VirtuaI-машине.

Виртуальная машина позволяет запускать более производительно несколько ОС на одном компьютерные одновременно.

Не включать технологию аппаратной виртуализации, основанной на специальной процессорной архитектуре.

Включает технологию аппаратной виртуализации, основанной на специальной процессорной архитектуре.

Программа Aptio Setup Utility – BIOS фирмы American Megatrends Inc на системных платах Dell Inc.

Название данной опции у данного производителя в данной версии BIOS (ноутбук):

Virtualization значение по умолчанию [Enabled]
Обозначение опции BIOSОписание опции в БИОСеПереведенное значение опции БИОС

Эта опция определяет, будет ли монитор виртуальных машин (VMM) использовать дополнительные аппаратные возможности, обеспечиваемые Intel (R) Virtualization Technology.

Введено = Включить Virtualization Technology.

Заводская настройка по умолчанию – Включена поддержка.

Программа BIOS InsydeH20 Setup Utility компании Insyde Software на на системных платах Hewlett-Packard Company (HP)

Название данной опции у данного производителя в данной версии BIOS:

Virtualization Technology значение по умолчанию [Disabled]

Данная опция находится на вкладке: «System Configuration»

Обозначение опции BIOSОписание опции в БИОСеПереведенное значение опции БИОС

This option specifies whether a Virtual Machine Monitor (VMM) can utilize the additional hardware capabilities provided by Intel(R) Virtualization Technology.
[Disabled]Disabled = Disable Virtualization Technology.Отключен = Отключить Технология виртуализации.
[Enabled]Enabled = Enable Virtualization Technology.

The factory default setting is Enabled.

Hardware VT enables a processor feature for running multiple simultaneous virtual machines allowing specialized software application to run in full isolation of each other. HP recommends that this feature remain disabled unless specialized unless specialized application are being user.

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

Обозначение опции BIOSОписание опции в БИОСеПереведенное значение опции БИОС
[ Enabled ]

Навигация и настройка значений БИОС InsydeH20 Setup Utility фирмы Insyde Software осуществляется стандартно, с помощью следующих клавиш:

KVM, PCI passthrough, Looking Glass и все-все-все

Искать выход долго не пришлось, но идея бить в бубен прожектором оказалась весьма странной. На тему проброса видеокарт в виртуальную машину интернет изобилует инструкциями различных времён и под различное железо. Чего стоит огромная статья на сайте Arch Linux’а [ 0 ]. Приведу сокращенную версию инструкции по пробросу видеокарты.

0. Проверяем, что железо поддерживает IOMMU

1. Включаем поддержку IOMMU в ядре.

GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash amd_iommu=on»
или
GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash intel_iommu=on»

Не забываем sudo update-grub .

2. Отбираем видеокарту у драйвера

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

04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2)
Kernel driver in use: nouveau
Kernel modules: nvidiafb, nouveau
04:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1)
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

Добавляем модули VFIO, чтобы они подгружались при загрузке.

Настраиваем модуль VFIO, чтобы он перехватывал устройства, не давая загрузиться основным драйверам. При необходимости добавляем в черный список, основной драйвер.

3. Перезагружаемся и проверяем, что всё получилось

DMAR: Intel® Virtualization Technology for Directed I/O
или
AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Interrupt remapping enabled
AMD-Vi: Lazy IO/TLB flushing enabled

Составные устройства попали в одну группу.

/sys/kernel/iommu_groups/15/devices/0000:01:00.0
/sys/kernel/iommu_groups/15/devices/0000:01:00.1

/sys/kernel/iommu_groups/16/devices/0000:02:00.0
/sys/kernel/iommu_groups/17/devices/0000:03:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.1

Драйвера KVM и VFIO загружены.

Видеокарта для гостевой ОС захвачена VFIO.

04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2)
Kernel driver in use: vfio-pci
Kernel modules: nvidiafb, nouveau
04:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1)
Kernel driver in use: vfio-pci
Kernel modules: snd_hda_intel

4. Настраиваем QEMU и запускаем гостевую ОС

sudo apt install qemu-kvm qemu-utils seabios ovmf virt-viewer

qemu-img create -f raw -o preallocation=full guest.img 50G
или
fallocate -l 50G guest.img

Запускаем виртуальную машину без проброса видеокарты для установки гостевой ОС. Так как стоит прицел на Looking Glass, то для гостевой стоит выбирать Windows 10. Windows 8/8.1 по последнем данным тоже поддерживаются.

#!/bin/bash
remote-viewer spice://127.0.0.1:5900&
sudo qemu-system-x86_64
-machine q35,accel=kvm
-enable-kvm
-cpu host,kvm=off,check
-smp cpus=2,sockets=1,cores=2,threads=1
-m 6G
-rtc base=localtime,clock=host
-device piix3-usb-uhci
-device usb-tablet
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd
-drive file=’w10.iso’,if= > -drive file=’virtio-win-0.1.141_st.iso’,if= > -drive file=’guest.img’,if= > -vga qxl
-spice port=5900,addr=127.0.0.1,disable-ticketing
-monitor stdio
-netdev user,
-device e1000,netdev=n1,mac=67:77:78:88:89:99
“$@”

5. Пробрасываем видеокарту в гостевую ОС

Для начала загрузимся с двумя видеокартами. Смотрим, что проброшенная карта появилась в системе, ставим на неё драйвера и убеждаемся, что они заработали.

#!/bin/bash
remote-viewer spice://127.0.0.1:5900&
sudo qemu-system-x86_64
-machine q35,accel=kvm
-enable-kvm
-cpu host,kvm=off,check
-smp cpus=2,sockets=1,cores=2,threads=1
-m 6G
-rtc base=localtime,clock=host
-device piix3-usb-uhci
-device usb-tablet
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd
-drive file=’virtio-win-0.1.141_st.iso’,if= > -drive file=’guest.img’,if= > -vga qxl
-spice port=5900,addr=127.0.0.1,disable-ticketing
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1, > -device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on
-device vfio-pci,host=04:00.1,bus=root,addr=00.1

-monitor stdio
-netdev user,
-device e1000,netdev=n1,mac=67:77:78:88:89:99
“$@”

После как проброшенная видеокарта заработала, и в диспетчере устройств пишет «Устройство работает нормально», запускаем виртуальную машину только с проброшенной видеокартой.

#!/bin/bash
sudo qemu-system-x86_64
-machine q35,accel=kvm
-enable-kvm
-cpu host,kvm=off,check
-smp cpus=2,sockets=1,cores=2,threads=1
-m 6G
-rtc base=localtime,clock=host
-device piix3-usb-uhci
-device usb-tablet
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd
-drive file=’virtio-win-0.1.141_st.iso’,if= > -drive file=’guest.img’,if= > -vga none
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1, > -device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on
-device vfio-pci,host=04:00.1,bus=root,addr=00.1
-monitor stdio
-netdev user,
-device e1000,netdev=n1,mac=67:77:78:88:89:99
“$@”

Подключаем к ней монитор и любуемся изображением рабочего стола гостевой ОС.

То место, где заканчиваются простые решения

И тут начинается, самое интересное. У кого-то, всё хорошо, картинка пошла и дальше всё просто. Мой опыт два раза споткнулся на стадии отсутствия изображения. Первый раз был проброс встроенной видеокарты процессора Intel 6700T HD 530, видеовыходы были пустые и неудача была списана на то, что встройки плохо прокидываются. Второй раз же пробрасывалась внешняя Nvidia GF210, которая уже была специально куплена для экспериментов. Результат был ещё более интересен. В non EFI режиме видеокарта успешно пробрасывалась и даже показывала картинку, но выключение гостевой ОС давало осечку .

Последующий проброс мог просто повесить хост. Пара часов лёгкого гугления приводит к тому, что проблема зависания видеокарты довольно распространённая. К этому ведёт как некорректное завершение работы виртуальной машины, так и с некоторым шансом даже корректное выключение. Как выход рекомендуют пробрасывать в EFI режиме. Но VBIOS Nvidia GF210 не поддерживает EFI…

Шить или не шить, вот в чем вопрос

Не шить. QEMU поддерживает подмену VBIOS при пробросе видеокарты. Но VBIOS ещё придётся научить поддерживать EFI режим. Обычно это рекомендуют проверять перед тем как начать проброс видеокарты, например здесь [ 2 ]. Но дело приходится иметь с тем, что есть, и искать свежую видеокарту с поддержкой EFI не хотелось. Значит нужно патчить VBIOS. Все операции выполняемые с VBIOS, делаются на свой страх и риск. Мной использовалось комплект ПО и инструкция к нему от сюда [ 3 ]. После считывания VBIOS получаем файл gt210.rom , патчим и на выходе имеем gt210_uefi.rom . Вот его и нужно подсунуть видеокарте при загрузке виртуальной машины.

#!/bin/bash
sudo qemu-system-x86_64
-machine q35,accel=kvm
-enable-kvm
-cpu host,kvm=off,check
-smp cpus=2,sockets=1,cores=2,threads=1
-m 6G
-rtc base=localtime,clock=host
-device piix3-usb-uhci
-device usb-tablet
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd
-drive file=’virtio-win-0.1.141_st.iso’,if= > -drive file=’guest.img’,if= > -vga none
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1, > -device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on,romfile=gt210_uefi.rom
-device vfio-pci,host=04:00.1,bus=root,addr=00.1
-monitor stdio
-netdev user,
-device e1000,netdev=n1,mac=67:77:78:88:89:99
“$@”

Запускаем виртуальную машину и смотрим.

Темнота

Выходы видеокарты сияли темнотой. В очередной раз мораль проходила испытание неудачей. Первое, что приходит в голову, гостевая ОС падает при старте. Логи, мне нужны её логи. Для этого запускаем vga_qxl.sh . Смотрим предыдущий запуск. А там всё хорошо, кроме того, что питание резко дёрнули. Получается, что оно работает, хотя и не работает. Первая идея была подключиться по RDP и посмотреть, что же там происходит, но всё же лучше для этого использовать VNC, например tightvnc [ 4 ]. Устанавливаем VNC, настраиваем на 5600 порт и прокидываем этот порт для доступа из хоста.

#!/bin/bash
sudo qemu-system-x86_64
-machine q35,accel=kvm
-enable-kvm
-cpu host,kvm=off,check
-smp cpus=2,sockets=1,cores=2,threads=1
-m 6G
-rtc base=localtime,clock=host
-device piix3-usb-uhci
-device usb-tablet
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd
-drive file=’virtio-win-0.1.141_st.iso’,if= > -drive file=’guest.img’,if= > -vga none
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1, > -device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on,romfile=gt210_uefi.rom
-device vfio-pci,host=04:00.1,bus=root,addr=00.1
-monitor stdio
-netdev user,
-device e1000,netdev=n1,mac=67:77:78:88:89:99
“$@”

Подключаемся и видим рабочую машину, только монитор у неё странный Generic Non-PnP Monitor (Универсальный монитор не PnP). Картинка есть, значит можно пробовать запускать Looking Glass.

Looking Glass

Хоть данная технология и использует OpenGL, после gl пробел не нужен. А вот почитать инструкцию [ 5 ] на сайте проекта нужно обязательно. Для гостевой ОС скачать приложение захвата экрана looking-glass-host.exe [ 6 ], скачать и установить Microsoft Visual C++ 2015 Redistributable [ 7 ], скачать драйвер для IVSHMEM устройства [ 8 ]. Для хоста ставим зависимости, скачиваем и собираем клиентское приложение.

#!/bin/bash
sudo apt-get install cmake libsdl2-dev libsdl2-ttf-dev nettle-dev libspice-protocol-dev libfontconfig1-dev libx11-dev fonts-freefont-ttf libconfig-dev
wget github.com/gnif/LookingGlass/archive/a12.tar.gz
tar -xf a12.tar.gz
cd LookingGlass-a12
mkdir client/build
cd client/build
cmake ../
make

Запускаем виртуальную машину с IVSHMEM устройством. Размер памяти в 32Mb выбран для разрешения 1920×1080.

#!/bin/bash
if [! -f /dev/shm/looking-glass ]; then
touch /dev/shm/looking-glass
chown `whoami`:kvm /dev/shm/looking-glass
chmod 660 /dev/shm/looking-glass
fi

sudo qemu-system-x86_64
-machine q35,accel=kvm
-enable-kvm
-cpu host,kvm=off,check
-smp cpus=2,sockets=1,cores=2,threads=1
-m 6G
-rtc base=localtime,clock=host
-device piix3-usb-uhci
-device usb-tablet
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd
-drive file=’virtio-win-0.1.141_st.iso’,if= > -drive file=’guest.img’,if= > -vga none
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1, > -device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on,romfile=gt210_uefi.rom
-device vfio-pci,host=04:00.1,bus=root,addr=00.1
-device ivshmem-plain,memdev=ivshmem,bus=pcie.0
-object memory-backend-file, > -monitor stdio
-netdev user,
-device e1000,netdev=n1,mac=67:77:78:88:89:99
“$@”

Подключаемся через VNC, устанавливаем драйвер на IVSHMEM устройство, возможно на него будет поставлен стандартный драйвер, находится в «Системные устройства». Запускаем looking-glass-host.exe. На хосте запускаем ./LookingGlass-a12/client/build/looking-glass-client .

На этом у меня заработала система с NVidia GF210, а затем по этому же маршруту удалось запустить Intel HD530. С разрешением экрана была маленькая проблемка, для смены на редкое разрешение, например 2048х1152, пришлось использовать Custom Resolution Utility [ 9 ].

Ещё один нюанс, при добавлении приложения looking-glass-host.exe в автозагрузку, нужно настроить автоматический вход пользователя, по соображениям безопасности гостевая ОС не даёт захватывать экран входа в систему.

Послесловие

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

Производительность. Накладные ресурсы на виртуализацию и не самая расторопная гостевая ОС не дадут с комфортом работать на слабом и средне-слабом железе. Потребуется мощный процессор не меньше 6-8 ядер, хорошая видеокарта для гостевой ОС, 16ГБ+ оперативной памяти, минимум по 8ГБ на каждую ОС. И танцы с бубном, чтобы выжать максимум из железа.
Терпение. Если сразу не заработает, то сил и времени придётся потратить прилично. Искать, читать, пробовать. Опять искать, читать и снова пробовать. Оставлю ещё несколько ссылок, которые мне попадались, возможно там будет ещё какая-нибудь полезная информация. [ 10 ] [ 11 ] [ 12 ]

ru.knowledgr.com

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

До разделения функциональности Нортбриджа и Саутбриджа между центральным процессором и Platform Controller Hub (PCH), виртуализация ввода/вывода не была выполнена центральным процессором, но вместо этого чипсетом.

Преимущества

Преимущества наличия IOMMU, по сравнению с прямым физическим обращением памяти, включают:

  • Большие области памяти могут быть ассигнованы без потребности быть смежными в физической памяти, IOMMU наносит на карту смежные виртуальные обращения к основным фрагментированным физическим адресам. Таким образом использования направленного ввода/вывода (разброс – собирают списки) можно иногда избегать.
  • Устройства, которые не поддерживают адреса памяти достаточно долго, чтобы обратиться ко всей физической памяти, могут все еще обратиться ко всей памяти через IOMMU, избежав накладных расходов, связанных с копированием буферов к и от адресуемого места в памяти peripheral.
  • Например, x86 компьютеры может обратиться больше чем к 4 гигабайтам памяти с особенностью Physical Address Extension (PAE) в x86 процессоре. Однако, обычное 32-битное устройство PCI просто не может обратиться к памяти выше границы на 4 гибибайта, и таким образом это не может непосредственно получить доступ к нему. Без IOMMU операционная система должна была бы осуществить отнимающие много времени буфера сильного удара (также известный как двойные буфера).
  • Память защищена от злонамеренных устройств, которые делают попытку нападений DMA и неисправных устройств, которые делают попытку неправедных передач памяти, потому что устройство не может читать или написать памяти, которая не была явно ассигнована (нанесенная на карту) для него. Защита памяти основана на факте что OS, бегущий на центральном процессоре (см. число), исключительно управляет и MMU и IOMMU. Устройства физически неспособны обойти или испортить формируемые управленческие столы памяти.
  • В виртуализации операционные системы гостя могут использовать аппаратные средства, которые определенно не сделаны для виртуализации. Более высокие исполнительные аппаратные средства, такие как видеокарты используют DMA, чтобы получить доступ к памяти непосредственно; в виртуальной окружающей среде все адреса памяти повторно нанесены на карту программным обеспечением виртуальной машины, которое заставляет устройства DMA терпеть неудачу. IOMMU обращается с этим переотображением, позволяя родным драйверам устройства использоваться в операционной системе гостя.
  • В некоторой архитектуре IOMMU также выполняет переотображение перерыва аппаратных средств способом, подобным стандартному переотображению адреса памяти.
  • Периферийное оповещение памяти может быть поддержано IOMMU. Периферийное использование PCI-СИГНАЛА PCIe Address Translation Services (ATS) расширение Page Request Interface (PRI) может обнаружить и сигнализировать о потребности в услугах распределителя памяти.

Для системной архитектуры, в которой ввод/вывод порта – отличное адресное пространство от адресного пространства памяти, не используется IOMMU, когда центральный процессор общается с устройствами через порты ввода/вывода. В системной архитектуре, в которой ввод/вывод порта и память нанесены на карту в подходящее адресное пространство, IOMMU может перевести доступы ввода/вывода порта.

Недостатки

Недостатки наличия IOMMU, по сравнению с прямым физическим обращением памяти, включают:

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

Виртуализация

Когда операционная система бежит в виртуальной машине, включая системы, которые используют паравиртуализацию, такую как Xen, это обычно не знает физические хозяином адреса памяти, к которой это получает доступ. Это делает обеспечение прямого доступа к компьютерной технике трудным, потому что, если бы гость OS попытался приказать аппаратным средствам выполнять доступ непосредственной памяти (DMA), используя физические гостем адреса, это, вероятно, испортило бы память, поскольку аппаратные средства не знают об отображении между физическими гостем и физическими хозяином адресами для данной виртуальной машины. Коррупции избегают, потому что гиперщиток или хозяин OS вмешиваются в операцию по вводу/выводу, чтобы применить переводы, вызывая задержку операции по вводу/выводу.

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

ru.knowledgr.com

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

До разделения функциональности Нортбриджа и Саутбриджа между центральным процессором и Platform Controller Hub (PCH), виртуализация ввода/вывода не была выполнена центральным процессором, но вместо этого чипсетом.

Преимущества

Преимущества наличия IOMMU, по сравнению с прямым физическим обращением памяти, включают:

  • Большие области памяти могут быть ассигнованы без потребности быть смежными в физической памяти, IOMMU наносит на карту смежные виртуальные обращения к основным фрагментированным физическим адресам. Таким образом использования направленного ввода/вывода (разброс – собирают списки) можно иногда избегать.
  • Устройства, которые не поддерживают адреса памяти достаточно долго, чтобы обратиться ко всей физической памяти, могут все еще обратиться ко всей памяти через IOMMU, избежав накладных расходов, связанных с копированием буферов к и от адресуемого места в памяти peripheral.
  • Например, x86 компьютеры может обратиться больше чем к 4 гигабайтам памяти с особенностью Physical Address Extension (PAE) в x86 процессоре. Однако, обычное 32-битное устройство PCI просто не может обратиться к памяти выше границы на 4 гибибайта, и таким образом это не может непосредственно получить доступ к нему. Без IOMMU операционная система должна была бы осуществить отнимающие много времени буфера сильного удара (также известный как двойные буфера).
  • Память защищена от злонамеренных устройств, которые делают попытку нападений DMA и неисправных устройств, которые делают попытку неправедных передач памяти, потому что устройство не может читать или написать памяти, которая не была явно ассигнована (нанесенная на карту) для него. Защита памяти основана на факте что OS, бегущий на центральном процессоре (см. число), исключительно управляет и MMU и IOMMU. Устройства физически неспособны обойти или испортить формируемые управленческие столы памяти.
  • В виртуализации операционные системы гостя могут использовать аппаратные средства, которые определенно не сделаны для виртуализации. Более высокие исполнительные аппаратные средства, такие как видеокарты используют DMA, чтобы получить доступ к памяти непосредственно; в виртуальной окружающей среде все адреса памяти повторно нанесены на карту программным обеспечением виртуальной машины, которое заставляет устройства DMA терпеть неудачу. IOMMU обращается с этим переотображением, позволяя родным драйверам устройства использоваться в операционной системе гостя.
  • В некоторой архитектуре IOMMU также выполняет переотображение перерыва аппаратных средств способом, подобным стандартному переотображению адреса памяти.
  • Периферийное оповещение памяти может быть поддержано IOMMU. Периферийное использование PCI-СИГНАЛА PCIe Address Translation Services (ATS) расширение Page Request Interface (PRI) может обнаружить и сигнализировать о потребности в услугах распределителя памяти.

Для системной архитектуры, в которой ввод/вывод порта – отличное адресное пространство от адресного пространства памяти, не используется IOMMU, когда центральный процессор общается с устройствами через порты ввода/вывода. В системной архитектуре, в которой ввод/вывод порта и память нанесены на карту в подходящее адресное пространство, IOMMU может перевести доступы ввода/вывода порта.

Недостатки

Недостатки наличия IOMMU, по сравнению с прямым физическим обращением памяти, включают:

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

Виртуализация

Когда операционная система бежит в виртуальной машине, включая системы, которые используют паравиртуализацию, такую как Xen, это обычно не знает физические хозяином адреса памяти, к которой это получает доступ. Это делает обеспечение прямого доступа к компьютерной технике трудным, потому что, если бы гость OS попытался приказать аппаратным средствам выполнять доступ непосредственной памяти (DMA), используя физические гостем адреса, это, вероятно, испортило бы память, поскольку аппаратные средства не знают об отображении между физическими гостем и физическими хозяином адресами для данной виртуальной машины. Коррупции избегают, потому что гиперщиток или хозяин OS вмешиваются в операцию по вводу/выводу, чтобы применить переводы, вызывая задержку операции по вводу/выводу.

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

IOMMU SWIOTLB

This article provides instructions for enabling and configuring Input Output Memory Management Unit and the Software Input Output Translation Lookaside Buffer for use with the Linux kernel.

Today’s computing uses a method of partitioning memory and each device such as a graphics card, PCI device, or USB device has to have memory mapped to be accessed by the device or application.

Traditionally IOMMU was used for memory mapping. This is setup when the system is initialized and can not be dynamically changed as the system is running so chip manufacturers such as Intel and AMD developed more advanced memory management methods.

In the Linux kernel we can manipulate the IOMMU using new mechanisms provided by SWIOTLB for Intel and others for architectures from AMD. 64-bit systems have enabled a huge amount of memory to be used in by the system and this memory needs mapping before it can be used. These kinds of terms are used across the Enterprise area of computing, particularly the Virtual-Machine sector but they can be used by anyone running a Linux kernel.

Contents

IOMMU

This is Input Output Memory Management Unit. In every system this hardware is integrated into a north bridge controller which setup the memory and is programmed by the firmware on your main-board. In recent years manufacturers have stopped integrating this as a North-Bridge chip and integrated it into the CPU itself. This is why if you want to upgrade your memory speed, type and so on you are now required to not only change the motherboard but the CPU as well.

Regardless the kernel needs to setup and read the mappings to be able to use your system memory efficiently.

Installation

Kernel

Move to the kernel directory and open the menuconfig utility:

Set the following options:

The above will allow the kernel to control the mappings in the Memory Mapping controller.

Build and install the kernel:

Configuration

The following options for controlling aspects of the memory mapping will need to be added to the kernel command-line in order to take effect. Doing so varies depending on the system’s bootloader. Common bootloaders include GRUB2 and Lilo. More information on bootloaders can be found here.

Generic options

AttributeDescription and options
iommu=offThis disables the IOMMU driver completely.
iommu=noforceDon’t force hardware IOMMU usage when it is not neede.
iommu=ForceThe use of the hardware IOMMU even when it is not actually needed (e.g. because iommu=softUse software bounce buffering (SWIOTLB) (default for Intel machines). This can be used to prevent the usage of an available hardware IOMMU. (read bellow for Intel SWIOTLB).

AMD64 systems

AttributeDescription and options
amd_iommu=nofullflush ,
amd_iommu=fullflush ,
amd_iommu=off ,
amd_iommu=force_isolation
Enable flushing of IO/TLB entries they are unmapped. Otherwise they are flushed before they will be reused, which is a lot of faster.
off = do not initialize any AMD IOMMU found in the system.
force_isolation = Force device isolation for all devices. The IOMMU driver is not allowed anymore to lift isolation requirements as needed. This option does not override iommu=pt .
amd_iommu_dump=0 ,
amd_iommu_dump=1
This is a boolean option: 0 = disabled, 1 = enabled
This is to dump the ACPI table for AMD IOMMU. With this option enabled, AMD IOMMU driver will print ACPI tables for AMD IOMMU during IOMMU initialization.
amd_iommu_intr=legacy ,
amd_iommu_intr=vapic
Specifies one of the following AMD IOMMU interrupt remapping modes:
legacy = Use legacy interrupt remapping.
mode.vapic = Use virtual APIC mode, which allows IOMMU to inject interrupts directly into guest. This mode requires kvm-amd.avic=1 . (Default when IOMMU HW support is present.)

Intel systems

Intel generally adopts “an-always-enable-it-if-it-is-supported” rule so most options are to turn off or disable the IOMMU functions.

AttributeDescription and options
intel_iommu=on ,
intel_iommu=off
This is a boolean option: on = enabled, off = disabled.
intel_iommu=igfx_offThis option turns off mapping for a graphics card and is the default state for this option. The gfx is mapped as normal device. If a gfx device has a dedicated DMAR unit, the DMAR unit is bypassed by not enabling DMAR with this option. In this case the gfx device will use physical address for DMA.
intel_iommu=forcedacWith this option iommu will not optimize to look for io virtual address below 32-bit forcing dual address cycle on pci bus for cards supporting greater than 32-bit addressing. The default is to look for translation below 32-bit and if not available then look in the higher range.
intel_iommu=strictThe default setting for this is disabled. This option on every unmap_single operation will result in a hardware IOTLB flush operation as opposed to batching them for performance.
intel_iommu=sp_offSuper Page which is by default enabled if supported, you can turn this off using this option.
intel_iommu=ecs_offBy default, extended context tables will be supported if the hardware advertises that it has support both for the extended tables themselves, and also PASID support. With this option set, extended tables will not be used even on hardware which claims to support them.

SWIOTLB

Software Input Output Translation Lookaside Buffer is an Intel technology which sort of bypasses the IOMMU and allows for a much more configurable memory management interface. Without going into the deep complexity of how this works, page tables are cached in the Lookaside Buffer reducing the need to constantly access physical RAM to map memory. This technology is also referred to as a bounce buffer as the physical address of the memory map is held in this virtual space of and IO is bounced between the physical IO and the Physical memory by this virtual lookaside buffer.

This allows the memory mapping to be carried out quickly and have a physical memory space available for use much faster than if it had to be created physically in RAM and presented to the system as usable.

Each IO TLB is referred to as a slab, this can be found in the swiotlb.h kernel header source file:

So this mean 1MB would be 8 slabs and the value used as the boot parameter is in slabs NOT size.

AttributeDescription and options
swiotlb=n’th amount of slabsThis specifies the amount of slabs to be used by IOTLB, each slab consists of 128K each which is 8 slabs per 1Mb(1024K), so a 64MB SWIOTLB would consist of 512 slabs. You can increase or decrease this value to allow for more buffering of virtual memory addresses in the buffer or not. Default is 64MB or 512 slabs.
swiotlb=forceThis option will force all system IO through the SWIOTLB so there will be no IOMMU controlled by the BIOS or the IOMMU driver elsewhere if one existed.

SWIOTLB for high input output (such as graphics)

For decades the problem has existed in that how would you get data in and out of the CPU and RAM quickly and efficiently especially for high throughput devices like file IO and graphic cards, etc.

Unfortunately the system is not only having to deal with that IO but many tasks all at the same time, the CPU and RAM may be very fast but if it cannot get the data out by either network, USB, storage device, or onto a screen via a graphics card it is a waste of time having a fast multiprocessing system.

Normally the system holds 4MB for normal operation and allows the rest to be used by other devices. The problem is that if a device overlaps or overflows into another then the system panics and can’t deal with it. Many new devices like Nvidia graphics cards and SCSI controllers have drivers now that allow the IOMMU values they use to be set.

There is no safe way this value can be set (adjusted) automatically because of the diversity of hardware configurations possible on the market. This means the end user has to design and build the system and decide for each use case the best setting for the system.

If one set a large SWIOTLB then one would need to instruct the driver of a device to utilize the larger amount of memory mapping buffer. Some hardware physically control this in the BIOS while others do not provide any control. For the most part, newer high end hardware permit system administrators to control this by modifying the above kernel options.

Some drivers try to automatically control this but as mentioned above can cause stability issues even kernel panic.

Simply setting a large SWIOTLB will not mean a faster IO will be achieved; the hardware must be instructed to use it. Rule of thumb is if 64MB is available then set a maximum remap IO for the driver of 4MB less. This would be 60MB in this case. If 128MB then max remap for the driver would be 124MB and so on.

Читайте также:  Как измерить площадь в AutoCAD
Ссылка на основную публикацию
Adblock
detector