Переназначка DMA IOMMU

На этой странице описывается функция повторного сопоставления IOMMU DMA (IOMMUv2), представленная в Windows 11 22H2 (WDDM 3.0). Сведения об изоляции GPU на основе IOMMU см. в статье об изоляции GPU IOMMU до WDDM 3.0.

Обзор

До версии WDDM 3.0 Dxgkrnl поддерживал только изоляцию IOMMU через 1:1 физическое отображение, то есть логические страницы, к которым обращается GPU, переводились на тот же физический номер страницы. Повторное сопоставление DMA IOMMU позволяет GPU получать доступ к памяти через логические адреса, которые больше не сопоставлены 1:1. Вместо этого Dxgkrnl может предоставлять логически смежные диапазоны адресов.

Dxgkrnl накладывает ограничение на GPU: графические процессоры должны иметь возможность получить доступ ко всей физической памяти, чтобы устройство было запущено. Если максимальный видимый адрес GPU не превышает максимального физического адреса, установленного в системе, Dxgkrnl завершает инициализацию адаптера сбоем. Предстоящие серверы и высокопроизводительные рабочие станции можно настроить с более чем 1 ТБ памяти, которая пересекает общее 40-разрядное ограничение адресного пространства для многих GPU. Переназначка DMA используется в качестве механизма, позволяющего графическим процессорам работать в этой среде.

Во время запуска Dxgkrnl определяет, требуется ли логическое переназначение, сравнивая самый доступный физический адрес устройства с памятью, установленной в системе. Если это необходимо, используется переназначение DMA для сопоставления диапазона логических адресов, находящегося в пределах видимых границ GPU, с любой физической памятью в системе. Например, если GPU имеет ограничение в 1 Тбайт, Dxgkrnl выделяет логические адреса из [0, 1 Тбайт), которые затем могут сопоставить с любой физической памятью в системе через IOMMU.

Логические и физические адаптеры

Dxgkrnl различает концепцию логического и физического адаптера. Физический адаптер представляет отдельное аппаратное устройство, которое может быть связано с другими устройствами в цепочке LDA. Логический адаптер представляет один или несколько связанных физических адаптеров.

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

Встроенная и дискретная поддержка GPU

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

Дискретные графические процессоры должны поддерживать ремаппинг DMA IOMMU, что необходимо для сертификации WDDM 3.0.

Изменения DDI

Следующие изменения DDI были внесены для поддержки повторного сопоставления IOMMU DMA.

Возможности драйвера

Для поддержки линейного преобразования требуются два набора крышек драйверов:

• Драйвер должен сообщить Dxgkrnl о своих ограничениях физической памяти; то есть, о самом высоком видимом физическом адресе с помощью DXGKQAITYPE_PHYSICAL_MEMORY_CAPS и связанной с ним структуры DXGK_PHYSICAL_MEMORY_CAPS.
• Драйвер должен указывать на поддержку линейного повторного отображения IOMMU с помощью DXGKQAITYPE_IOMMU_CAPS и связанной структуры DXGK_IOMMU_CAPS. Указывая на поддержку, драйвер указывает, что все описанные далее DDIs поддерживаются и используются.

Обе эти условия должны быть выполнены до того, как Dxgkrnl запускает устройство, используя DXGKDDI_START_DEVICE, чтобы устройство можно было создать и подключить к домену IOMMU перед доступом к памяти. Линейное перемещение можно сделать только в том случае, если устройство не ссылается на существующую физическую память.

Эксклюзивный доступ

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

Чтобы справиться с этой ситуацией, начиная с Windows 10 версии 1803 (WDDM 2.4), KMD должен реализовать следующую пару DDI для вызова Dxgkrnl :

• DxgkDdiBeginExclusiveAccess вызывается для уведомления KMD о том, что переключение домена IOMMU происходит.
• DxgkDdiEndExclusiveAccess вызывается после завершения коммутатора домена IOMMU.

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

Между этими двумя вызовами Dxgkrnl делает следующие гарантии:

• Планировщик приостановлен. Все активные рабочие нагрузки сбрасываются, и новые рабочие нагрузки не отправляются в оборудование или не планируются.
• Другие вызовы DDI не выполняются.

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

Списки дескриптора адресов

Чтобы поддерживать режимы физического и логического доступа и переключаться между двумя режимами легко во время выполнения, Dxgkrnl предоставляет DXGK_ADL структуру , описывающую список дескрипторов адресов (ADL). Эта структура данных похожа на MDL, но описывает массив страниц, которые могут быть физическими или логическими. Так как эти страницы могут быть логическими, адреса, описанные ADL, не могут быть сопоставлены с виртуальным адресом для прямого доступа к ЦП.

операция DXGK_OPERATION_MAP_APERTURE_SEGMENT2 для DxgkDdiBuildPagingBuffer

VidMm предоставляет режим буфера DXGK_OPERATION_MAP_APERTURE_SEGMENT2 для сопоставления памяти с диафрагмой, так как в предыдущей версии используется MDL, несовместимый с логическими адресами. Обратный вызов DxgkddiBuildpagingbuffer драйверов WDDM 3.0, поддерживающих перенаправление логических адресов, получают вызовы в режим DXGK_OPERATION_MAP_APERTURE_SEGMENT2, и перестают получать вызовы в исходный режим DXGK_OPERATION_MAP_APERTURE_SEGMENT.

Эта операция необходима для поддержки логического перемаппинга DMA. Он ведет себя аналогично исходной операции, но предоставляет DXGK_ADL вместо MDL.

typedef enum _DXGK_BUILDPAGINGBUFFER_OPERATION
{
#if (DXGKDDI_INTERFACE_VERSION >= DXGKDDI_INTERFACE_VERSION_WDDM2_9)
    DXGK_OPERATION_MAP_APERTURE_SEGMENT2 = 17,
#endif //  DXGKDDI_INTERFACE_VERSION
};

// struct _DXGKARG_BUILDPAGINGBUFFER:
struct
{
    HANDLE  hDevice;
    HANDLE  hAllocation;
    UINT    SegmentId;
    SIZE_T  OffsetInPages;
    SIZE_T  NumberOfPages;
    DXGK_ADL Adl;
    DXGK_MAPAPERTUREFLAGS Flags;
    ULONG   AdlOffset;
    PVOID   CpuVisibleAddress;
} MapApertureSegment2;

Чтобы выбрать операцию DXGK_OPERATION_MAP_APERTURE_SEGMENT2 , драйвер должен указать поддержку вызовов MapApertureSegment2 в ограничениях управления памятью:

typedef struct _DXGK_VIDMMCAPS {
  union {
    struct {
        ...
        UINT MapAperture2Supported : 1;
        ...
    }
    ...
} DXGK_VIDMMCAPS;

Ограничения управления памятью DXGK_VIDMMCAPS являются частью структуры данных DXGK_DRIVERCAPS . Драйвер не может использовать функцию повторного сопоставления DMA (т. е. повторное сопоставление логических адресов) без этой поддержки.

Для некоторых драйверов может потребоваться доступ К ЦП к памяти во время вызова MapApertureSegment2 . Эта функция также предоставляется с помощью другого параметра MapApertureSegment2.CpuVisibleAddress . Этот адрес является виртуальным адресом в режиме ядра, допустимым до тех пор, пока выделение сопоставляется с сегментом диафрагмы. То есть этот адрес будет освобожден сразу после вызова соответствующего DXGK_OPERATION_UNMAP_APERTURE_SEGMENT для того же выделения.

Этот адрес может не потребоваться для всех выделений. Флаг MapApertureCpuVisible был добавлен в флаги выделения, чтобы указать, когда этот адрес является обязательным.

Если MapApertureCpuVisible не указан, MapApertureSegment2.CpuVisibleAddress имеет значение NULL для операций DXGK_OPERATION_MAP_APERTURE_SEGMENT2 .

MapApertureCpuVisible является частью функции DxgkDdiBuildPagingBufferMapAperatureSegment2, поэтому драйвер должен задать DXGK_VIDMMCAPS MapAperature2Supported для использования этого поля. Если MapAperature2Supported не задан, но драйвер указывает MapApertureCpuVisible, вызов DxgkDdiCreateAllocation завершается ошибкой.

Кроме того, чтобы получить операцию DXGK_OPERATION_MAP_APERTURE_SEGMENT2, драйвер должен установить флаг DXGK_ALLOCATIONINFOFLAGS_WDDM2_0 AccessedPhysically. Если AccessedPhysically не задан, любое выделение, указывающее сегмент апертуры в поддерживаемом наборе сегментов, преобразуется в неявный сегмент системной памяти, который не получает вызовов MAP_APERTURE (так как нет диапазонов апертуры для сопоставления).

Вкратце, чтобы корректно получить адрес ЦП для выделения системной памяти, драйвер должен задать следующие флаги/возможности:

• DXGK_DRIVERCAPS::MemoryManagementCaps.MapAperture2Supported = 1
• DXGK_ALLOCATIONINFOFLAGS_WDDM2_0::MapApertureCpuVisible = 1
• DXGK_ALLOCATIONINFOFLAGS_WDDM2_0::AccessedPhysically = 1

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

Службы управления памятью

Существует три основных требования для функций управления памятью:

1. Возможность управления физической памятью. Эта возможность может включать выделение памяти с помощью функций непагированной памяти, таких как MmAllocatePagesforMdl или MmAllocateContiguousMemory, и функций, связанных с разборкой страниц памяти, таких как ZwCreateSection или ZwAllocateVirtualMemory. Также требуется возможность выражения диапазонов пространства ввода-вывода.

2. Возможность отображения логического адреса, видимого для GPU, из физической памяти. Эта возможность обеспечит вызывающую сторону списком логических страниц (как массив номеров PFN, как в MDL), к которым можно запрограммировать доступ GPU. Вызов этих функций гарантирует, что базовые физические страницы заблокированы и не подлежат выгрузке.

3. Возможность сопоставлять виртуальные адреса ЦП из физической памяти как в пользовательском режиме, так и в режиме ядра с указанным типом кэша (cached vs WriteCombined).

В следующей таблице перечислены DDIs и связанные входные структуры, представленные для описания выделения физической памяти и сопоставления логических или виртуальных представлений. Эти DDIs представляют собой обновленный набор для замены предыдущих обратных вызовов, предоставленных драйверам для менеджмента сопоставлениями IOMMU (DxgkCbAllocatePagesforMdl, DxgkCbAllocateContiguousMemory, DxgkCbMapMdlToIoMmu). Для драйверов WDDM 3.0, поддерживающих логическую перемаценку, эти старые функции обратного вызова устарели и не могут использоваться. Вместо этого драйвер должен использовать следующие функции обратного вызова управления памятью.

Функции обратного вызова должны вызываться в IRQL <= APC_LEVEL. Начиная с версии WDDM 3.2, драйверы, которые вызывают любую из этих функций, проверяются на соответствие этому требованию и вызывают проверку ошибок, если уровень IRQL — DISPATCH_LEVEL или выше.

Изменения INF

Каждый поддерживаемый тип устройства должен добавить следующие ключ реестра и значение в соответствующий раздел INF:

[DMAr.reg]
; Add REG_DWORD 'DmaRemappingCompatible' with value of 3 
HKR,Parameters,DmaRemappingCompatible,0x00010001,```3

Это значение сообщает PnP, что устройство поддерживает повторную настройку DMA. Dxgkrnl и HAL затем координируют действия, чтобы определить, какой тип режима сопоставления следует использовать (ремаппинг, сквозное отображение и т. д.).

Хотя этот раздел реестра присутствовал в более ранних версиях Windows, значение "3", начиная с Windows 10 версии 1803 (WDDM 2.4), является уникальным и игнорируется в более старых сборках, которые его не поддерживают. Это уникальное значение позволяет разработчикам драйверов задать этот параметр в файле INF и не беспокоиться о проблемах совместимости с более старыми версиями.