2. 整栈全景图：一次 blob 分配要穿过多少层

上一篇我们回答了“为什么要有 blob”。这一篇我们回答“在哪里”——一次 blob 分配从 guest 应用出发到 host GPU 真正吐出一块存储中间要穿过多少层每一层负责什么、不负责什么我们暂时不深入任何一层的实现只建立“端到端”的空间感为后续每一篇钉下坐标。读完这篇你脑子里应该有一张能随手画出的分层图。1、先把地图立起来上一篇文末那张图这一篇是主角。我们把它竖起来标上层号API 调用RESOURCE_CREATE_BLOBvirtqueuevirgl_renderer_* APIget_blob 回调KVM ioctl① Guest 应用 / Mesavirgl · venus② Guest 内核 virtio-gpu 驱动drivers/gpu/drm/virtio③ virtqueue · 传输层④ VMM · QEMU / crosvm⑤ virglrenderer 核心⑥ 后端 backendvrend · venus · drm · rocm⑦ Hypervisor · KVMEPT / NPT / stage-2一共7 层。它们分属三个“世界”Guest 世界①②跑在虚拟机里只能看见 guest 物理地址对 host 一无所知。VMM 世界③④⑤⑥host 上的用户态进程翻译 guest 的请求调度真实资源。Hypervisor 世界⑦内核态掌管两个世界之间的地址翻译。blob 机制的全部复杂度本质上来自一个请求要跨越这三个世界。下面逐层拆解责任边界。2、逐层拆解谁负责什么2.1 ① Guest 应用 / Mesa它想要什么一块能给 GPU 用的内存。可能是 Vulkan 的VkDeviceMemory、OpenCL buffer或者一张纹理。它做什么调用 Mesa 里的 virtio 驱动virgl走 GL、venus走 Vulkan。驱动把这个诉求翻译成“我要一个 blob 资源大小 N用途是可映射 / 可共享 / ……”。它不知道什么host 上到底是谁、用什么方式满足它。对它而言下面全是黑箱。责任边界把“API 层的内存诉求”翻译成“virtio-gpu 的 blob 语义”。2.2 ② Guest 内核 virtio-gpu 驱动它做什么位于drivers/gpu/drm/virtio。它把 Mesa 的请求封装成一条真正的协议命令VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB填好blob_mem、blob_flags、blob_id、size必要时附上 guest 页的 iovecscatter-gather 列表。关键动作分配 guest 侧的 GEM 对象、分配 res_id把命令塞进 virtqueue。责任边界guest 内的资源记账 把请求序列化成 virtqueue 命令。它是 guest 世界通向外部的唯一出口。2.3 ③ virtqueue · 传输层它做什么virtio 的标准环形队列。命令从 guest 的 control queue 入队VMM 从另一端出队。它不关心命令的语义。它只搬运字节 通知kick / interrupt。责任边界纯传输。它是①②Guest 世界与④⑤⑥VMM 世界的物理分界线。2.4 ④ VMM · QEMU / crosvm它做什么从 virtqueue 取出命令识别出这是RESOURCE_CREATE_BLOB翻译成对 virglrenderer 的库调用virgl_renderer_resource_create_blob(args)。它还负责一件大事后面第 8 篇专讲当 blob 需要映射进 guest 时由它在 guest 物理地址空间里开窗口、把 host 内存接进去并驱动 KVM 建立映射。责任边界协议 ↔ 库 API 的翻译官以及 guest 地址空间的“房东”。它同时脚踏 VMM 世界与 Hypervisor 世界。2.5 ⑤ virglrenderer 核心它做什么virgl_renderer_resource_create_blob见 virglrenderer.c做通用校验——检查blob_mem组合是否合法、res_id 是否唯一、iovec 大小是否够——然后把“真正去搞到存储”这件事委托给后端调用ctx-get_blob(...)。它不知道什么具体后端GL/Vulkan/rocm如何分配。它只定义契约给我一个virgl_context_blob。责任边界通用编排 后端分发。它是“骨架”把差异留给后端填。2.6 ⑥ 后端 backend它做什么真正干活的地方。根据blob_mem × blob_flags后端决定用哪种 host 存储后端典型产出vrendGL一个 host GL 资源pipe_resourcevenusVulkandma-buf fd 或 opaque fd Vulkan UUIDdrm native ctxGEM opaque handlerocm/hsakmt虚拟地址 / SVM它把结果填进virgl_context_blob交还给核心⑤核心再据此建出virgl_resource。责任边界把抽象的 blob 诉求兑现成一块真实的 host 存储句柄。这是整条链“落地”的一层。2.7 ⑦ Hypervisor · KVM它做什么当④要把 host 内存映射进 guest 时通过KVM_SET_USER_MEMORY_REGION登记一个 memory slot并在二级页表Intel EPT / AMD NPT / ARM stage-2里建立guest 物理地址 → host 物理页的翻译。它成就了什么guest CPU 访问那段 BAR 时硬件直接翻译到 host 显存——零 VM-exit、零拷贝。这正是 blob 相对 conventional 模型的性能根基。责任边界两个世界之间的地址翻译。它不理解图形只理解页。3、把一次分配走一遍时序把 7 层串成一次完整的“host 分配可映射 blob”的时序你会看到责任是如何接力的⑦ KVM⑥ 后端⑤ virglrenderer④ QEMU③ virtqueue② Guest KMD① Mesa⑦ KVM⑥ 后端⑤ virglrenderer④ QEMU③ virtqueue② Guest KMD① Mesa若需映射后续再发 RESOURCE_MAP_BLOB申请一块 GPU 内存1RESOURCE_CREATE_BLOB(mem/flags/id/size)2出队命令3virgl_renderer_resource_create_blob(args)4通用校验5get_blob(...)6填好 virgl_context_blob(fd/handle/va)7资源创建完成 (res_id)8(稍后) RESOURCE_MAP_BLOB9取出 blob 的 fd 并 mmap10KVM_SET_USER_MEMORY_REGION11建 EPT/NPT 映射12guest 可直接读写这段 BAR13注意这里的一个关键事实“创建 blob”和“映射 blob”是两步。第 410 步只是拿到一块 host 存储真正让 guest CPU 看见它要等后面的RESOURCE_MAP_BLOB第 11 步起。这个“创建与映射分离”的设计是后面第 4 篇的重点。4、三条贯穿始终的“暗线”7 层之外有三样东西不属于某一层而是沿着整条链流动。提前点名后面每次遇到你就能认出它们res_idguest 分配的资源号是 guest / VMM / 后端三方共同的“身份证”。跨层引用同一块资源全靠它。blob 的存储句柄fd / handle / va由⑥产出被④用来 mmap最终喂给⑦。它就是virgl_context_blob承载的东西——后端与核心之间的交接物第 11 篇主角。map_info缓存属性从后端一路传到 hypervisor 的页表里决定这段内存是 WC 还是 WB。一个字段纵贯⑥→④→⑦三层任何一环不一致都会出问题第 10 篇专讲。5、本篇小结与下一站这一篇我们建立了空间感一次 blob 分配跨越7 层、3 个世界Guest / VMM / Hypervisor每一层责任清晰guest 侧负责“翻译诉求 序列化”virglrenderer 核心负责“编排 分发”后端负责“兑现存储”KVM 负责“地址翻译”“创建 blob”与“映射 blob”是分离的两步有三条暗线res_id、存储句柄、map_info沿链流动是后续多篇的连接点。导航上一篇第 1 篇 为什么需要 blob从 conventional resource 的困局说起下一篇第 3 篇 blob 的三维输入模型blob_mem × blob_flags × blob_id