一、drm_native_context 的原理传统virgl的工作方式是把 guest 的 OpenGL 命令翻译成宿主机的 GL 调用(命令流翻译)。DRM native context(原生上下文)则采用完全不同的思路:它让guest 里的原生用户态驱动(如 radeonsi / RADV)直接运行，把 guest 驱动产生的amdgpu 内核 ioctl通过 virtio-gpu 转发给宿主机的 amdgpu 内核驱动执行。相当于把宿主机的/dev/dri/renderD*以半虚拟化(paravirtualize)的方式"直通"给 guest。关键抽象是一套CCMD(context command)协议:guest 侧把每个 amdgpu 操作(创建 BO、提交命令流、query info 等)序列化成vdrm_ccmd_req，经 virtio-gpu 的submit_cmd传到宿主机 virglrenderer，由 amdgpu backend 解码并调用真正的 libdrm_amdgpu。相比 virgl 命令流翻译，native context 的优势在于:guest 直接运行原生驱动，GL/Vulkan 特性覆盖度与宿主机一致，无需在 virglrenderer 中逐特性适配;命令以 ioctl 粒度转发，语义损失小，性能更接近裸机;guest 与宿主机使用同一套 UMD 代码，维护成本低。为什么性能远好于命令流翻译virgl(命令流翻译)的开销来自"在宿主机上把 guest 的 GL 语义重新走一遍":双重驱动栈:guest 的 GL 调用先被翻译成中间命令流,host 端 virglrenderer 再用宿主机的 GL/Mesa 驱动重新解释执行——等于跑了两套用户态驱动;着色器重编译:guest 的 GLSL/SPIR-V 要在 host 侧重新编译成 GPU ISA,首帧/切换 shader 时延明显;状态重验证 + 每调用往返:大量glXxx调用逐个跨界翻译、校验,CPU 开销高、批处理差;纹理/缓冲拷贝:资源常需在两套驱动的表示间转换或拷贝。native context 把边界下移到ioctl 粒度,几乎消除了上述开销:单套 UMD:guest 直接运行原生 radeonsi/RADV,host 端不再跑 GL 驱动,只把 amdgpu ioctl 转发给内核,无二次翻译;着色器只编译一次:在 guest 内用原生编译器生成最终 ISA,host 直接执行,无重编译;命令缓冲批量提交:guest 攒好整个 command buffer 后经一次EXECBUFFER下发,跨界往返次数大幅减少;零拷贝共享:BO 通过 blob 资源在 guest/host 间共享(blob_id↔res_id↔handle映射),避免数据搬运。结果是:CPU 侧开销接近直通(passthrough),GPU 侧本就是真实硬件执行,整体性能显著优于 virgl、接近裸机;且因为不需要在 virglrenderer 里逐特性适配 GL/Vulkan,新特性天然可用。代价是安全边界从"GL 语义"下沉到"内核 ioctl",隔离性弱于命令流翻译。数据流总览