Pruebas en modo kernel de características de WDDM
En este artículo se describe el diseño de la infraestructura de pruebas en modo kernel en WDDM que se agregó en Windows 11 versión 24H2 (WDDM 3.2). Esta infraestructura permite probar y validar controladores que no admiten entornos de ejecución D3D, como controladores para algunos dispositivos NPU. También se puede usar para validar los controladores que admiten entornos de ejecución D3D sin implicar el tiempo de ejecución D3D.
Información general
Hay escenarios en los que se introducen nuevos dispositivos de proceso basados en WDDM o MCDM y los controladores para estos dispositivos no admiten entornos de ejecución D3D. Para ayudar a validar estos controladores, la funcionalidad se agrega a Dxgkrnl para realizar la validación solo mediante thunks en modo kernel; es decir, sin implicar al controlador en tiempo de ejecución D3D y en modo de usuario (UMD).
Esta infraestructura también permite realizar pruebas de la característica WDDM mediante una configuración precisa sin tener que pasar por un entorno de ejecución D3D o un UMD, lo que puede complicar las cosas.
Las DDIs se presentan para crear un búfer de comandos en modo kernel para un conjunto determinado de comandos. Los comandos son sencillos, por lo que casi cualquier nodo de ejecución debe poder ejecutarlos mediante sombreadores precompilados u otros medios.
Para admitir esta funcionalidad, el controlador en modo kernel (KMD) debe proporcionar la siguiente compatibilidad:
- Informe de que la característica DXGK_FEATURE_KERNEL_MODE_TESTING está habilitada.
- Implemente la interfaz de características de DXGKDDI_KERNELMODETESTINGINTERFACE .
- Proporcione información sobre qué nodo de ejecución admite la compilación y ejecución de los búferes de comandos de prueba.
- Compatibilidad con la creación de una cola de contexto o hardware sin datos de controladores privados. Normalmente, el formato de los comandos de controlador privado es necesario para enviar una carga de trabajo a un dispositivo. La interfaz de prueba permite el envío de cargas de trabajo sin datos de controladores privados.
- Compatibilidad con la ejecución de búferes de comandos creados por pfnBuildTestCommandBuffer en cualquier nodo del dispositivo que admita la característica.
- Admite un identificador de asignación NULL en las DDIs de paginación (TRANSFERENCIA, RELLENO, etc.).
Esta característica solo se usa cuando la firma de pruebas está habilitada en la máquina.
Las pruebas HLK que usan esta característica se desarrollarán.
Cambios de DDI
Las estructuras y enumeraciones siguientes se actualizaron para admitir pruebas en modo kernel:
DXGK_FEATURE_KERNEL_MODE_TESTING se agrega a la enumeración DXGK_FEATURE_ID.
SupportBuildTestCommandBuffer se agrega a la estructura DXGK_NODEMETADATA_FLAGS .
TestContext se agrega a la estructura DXGK_CREATECONTEXTFLAGS .
TestQueue se agrega a la estructura D3DDDI_CREATEHWQUEUEFLAGS .
Se agregan las siguientes DDIs, estructuras y enumeración para admitir pruebas en modo kernel:
Se agrega la interfaz de característica DXGKDDI_KERNELMODETESTINGINTERFACE, con DXGKDDI_BUILDTESTCOMMANDBUFFER::p fnBuildTestCommandBuffer como único miembro de interfaz.
Compatibilidad de informes con la característica de pruebas en modo kernel
El sistema operativo llama a la función DxgkDdiQueryFeatureSupport de KMD con el identificador de característica de DXGK_FEATURE_KERNEL_MODE_TESTING agregado para comprobar si el controlador admite pruebas en modo kernel. El KMD debe informar de que se admite la característica.
A continuación, el sistema llama a DxgkDdiQueryFeatureInterface con el mismo identificador de característica para obtener el puntero de función de interfaz para pfnBuildTestCommandBuffer. KMD debe implementar esta función y proporcionar su puntero para la interfaz DXGKDDI_KERNELMODETESTINGINTERFACE.
Generación de informes de nodos de ejecución que admiten pruebas en modo kernel
SupportBuildTestCommandBuffer se agrega a la estructura DXGK_NODEMETADATA_FLAGS . KMD debe establecer esta marca para indicar que el nodo puede ejecutar búferes de comandos compilados por pfnBuildTestCommandBuffer. Se recomienda que tantos nodos como sea posible admitan la característica.
Creación de un contexto sin datos privados
TestContext se agrega a DXGK_CREATECONTEXTFLAGS para indicar que un contexto es un contexto de prueba. Esta marca solo tiene efecto cuando la firma de prueba está habilitada.
DxgkDdiCreateContext de KMD debe admitir la creación de un contexto sin datos privados para cada nodo que admita la ejecución de búferes de comandos generados por pfnBuildTestCommandBuffer. Para indicar esta compatibilidad, establezca la marca TestContext en Marcas durante la creación del contexto.
Creación de una cola de hardware sin datos privados del controlador
TestQueue se agrega a D3DDDI_CREATEHWQUEUEFLAGS para indicar que una cola de hardware es una cola de pruebas. Esta marca solo tiene efecto cuando la firma de prueba está habilitada.
DxgkDdiCreateHwQueue de KMD debe admitir la creación de una cola de hardware sin datos privados del controlador.
Creación de un búfer de comandos
PfnBuildTestCommandBuffer de KMD compila un búfer de comandos con instrucciones específicas del dispositivo para un conjunto de comandos simples. KMD devuelve un puntero a esta función de DxgkDdiQueryFeatureInterface(DXGK_FEATURE_KERNEL_MODE_TESTING).
Se envía un único comando de prueba a pfnBuildTestCommandBuffer. Actualmente se admiten los siguientes comandos:
| Comando | Descripción |
|---|---|
| D3DDDI_TESTCOMMAND_COPY | Copia bytes mediante direcciones virtuales de GPU de origen y destino. |
| D3DDDI_TESTCOMMANDBUFFER_FILL | Rellena una ubicación de memoria con un patrón. |
Los comandos de prueba se basan en el uso de direcciones virtuales de GPU. El sistema operativo garantiza que las máquinas virtuales de GPU se asignan a las asignaciones creadas con un tipo de asignación estándar de D3DKMT_STANDARDALLOCATIONTYPE_EXISTINGHEAP o D3DKMT_STANDARDALLOCATIONTYPE_INTERNALBACKINGSTORE.
El búfer de comandos generado y los datos privados se devuelven al modo de usuario. Cuando se envía el búfer de comandos para su ejecución, la llamada procede del modo de usuario. Una aplicación malintencionada podría cambiar el contenido del búfer y los datos privados. Es responsabilidad de KMD validar tanto el búfer de comandos como los datos del controlador privado para evitar las comprobaciones de errores.
El búfer de comandos generado no debe contener instrucciones con privilegios.
Un controlador cliente en modo de usuario (por ejemplo, Cuda) envía el búfer de comandos generado para su ejecución mediante D3DKMTSubmitCommand o D3DKMTSubmitCommandToHwQueue. En el futuro, el contenido del búfer se enviará como parte del envío en modo de usuario.
Cuando se envía un búfer de comandos generado para su ejecución, se garantiza que el búfer de comandos contiene instrucciones de dispositivo para un único comando de prueba.
El búfer de comandos generado se envía al nodo que corresponde al hContext pasado a pfnBuildTestCommandBuffer.
El tamaño del búfer DMA (pDmaBuffer) está limitado a 4 KB y el tamaño de los datos del controlador privado DMA (pDmaBufferPrivateData) está limitado a 1 KB.