4. host-visible 内存区与 MAP/UNMAP_BLOB 命令

上一篇我们拆开了blob_mem × blob_flags × blob_id三维输入并留了一个悬念MAPPABLE到底意味着什么host 分配的内存究竟怎么“出现”在 guest 里这一篇专门回答它。我们会引出host-visible 内存区这个容器以及RESOURCE_MAP_BLOB/UNMAP_BLOB这对命令还有那个纵贯三层、一路要传到 hypervisor 页表的map_info。在进入正题之前先聊聊虚拟化的理想安全模型。在虚拟化世界里最理想的安全模型是每个域虚拟机之间都无法越权访问对方最好做到完全互不访问。但这样的理想模型因性能开销太大根本无法落地到生产环境。因此必须设计安全的域间互访机制——安全与互访由此成为虚拟化设计中的一对矛盾也正是虚拟化最有趣、最有魅力的地方。从整个角度来看我们这个专栏讲的就是存储资源的域间互访。好言归正传。1、核心难题两个地址空间如何“对齐”回顾一下矛盾的本质guest 应用只认识guest 物理地址GPAhost 分配的 blob 存储是 host 进程里的一段host 虚拟地址HVA。conventional 模型靠“拷贝”回避了这个矛盾——两边各存一份用TRANSFER搬字节。blob 的MAPPABLE则要正面解决它让同一块 host 物理内存同时出现在 guest 的地址空间里两边看到的是同一份数据零拷贝。这里的描述是从 host 视角出发把 host 内存导入 guest。但要真正理解 host-visible 这个词要把视角反过来看。先看它的字面意思host 端可见——它在告诉你我原本是 guest 里的东东现在需要一种机制让 host 端也能看到我。毕竟普通用户使用虚拟机时总是习惯以虚拟机guest为主角来看待问题。要做到这一点需要三样东西配合一个在 guest 物理地址空间里预留好的窗口用来安放这些 host 内存 —— 这就是 host-visible 内存区一对协议命令让 guest 主动请求“把某个 blob 映射进那个窗口”——RESOURCE_MAP_BLOB/UNMAP_BLOB一个缓存属性协商保证两边对这段内存的缓存理解一致 ——map_info。2、host-visible 内存区guest 里的一块“公共停车场”virtio-gpu 设备通过 PCI 暴露一段特殊的地址窗口规范里叫host-visible memory region用 shmidVIRTIO_GPU_SHM_ID_HOST_VISIBLE标识。它在 guest 眼里就是设备 BAR 上的一大段物理地址空间。你可以把它想象成一个公共停车场停车场本身整段 region在虚拟机启动时就规划好了占据一段固定的 GPA 范围每一个被映射的 blob就是停进去的一辆车占据停车场里的一个offset 大小guest 拿到的“车位号”就是这个 offset —— 它据此算出 GPA然后就能直接读写。这个设计的妙处在于guest 物理地址空间的窗口是预留好的、固定的映射 blob 只是往窗口里“填内容”不需要每次都重新协商 guest 的地址布局。Guest 物理地址空间映射到host-visible region · PCI BARoffset 0blob Aoffset Nblob Boffset ...空闲车位普通 RAMHost 物理显存 / Vulkan memory3、创建与映射为什么是分离的两步第 2 篇我们强调过“创建 blob”和“映射 blob”是两条独立的命令。现在可以讲清为什么这样设计了。RESOURCE_CREATE_BLOB只负责搞到一块 host 存储后端分配、导出 fd。这一步的产物是一个 fd被 VMM 记在资源表里但还没进 guest 地址空间。RESOURCE_MAP_BLOBguest 显式请求“现在把这个资源映射进 host-visible region”。VMM 才真正mmap那个 fd并在停车场里分配 offset。RESOURCE_UNMAP_BLOB反过来把车开走释放 offset撤销映射。分离的好处不是每个 blob 都需要映射。很多 blob 只在 host 侧被 GPU 使用比如中间渲染目标guest CPU 根本不看那就永远不必占用宝贵的 region 窗口。窗口是稀缺资源可以按需 map / unmap 复用而存储本身fd可以长期存在。生命周期解耦存储的所有权谁关 fd和映射的生命周期谁 unmap是两码事可以分别管理。KVM后端VMMGuestKVM后端VMMGuestfd 记在资源表未进 guest 地址空间RESOURCE_CREATE_BLOB1get_blob → 得到 fd2RESOURCE_MAP_BLOB(res_id)3mmap(fd) → HVA在 region 里分配 offset4KVM_SET_USER_MEMORY_REGION(GPA 窗口 → HVA)5返回 offset车位号6按 offset 直接读写7RESOURCE_UNMAP_BLOB(res_id)8撤销该段 memory slot94、map_info一路传到硬件页表的缓存属性映射不仅仅是“地址对上”还得缓存属性对上。同一块物理内存如果 host 端按 write-combiningWC访问、guest 端却按 write-backWB缓存就会出现脏数据、花屏、乱序可见等一致性灾难。map_info就是携带这条缓存语义的字段。它的取值在 virglrenderer 里大致是VIRGL_RENDERER_MAP_CACHE_CACHEDWB可缓存VIRGL_RENDERER_MAP_CACHE_WCwrite-combiningVIRGL_RENDERER_MAP_CACHE_NONE不缓存 / 未指定它的来历在 venus 后端里看得很清楚vkr_device_memory.c——由 Vulkan 内存的属性推导if(blob_flagsVIRGL_RENDERER_BLOB_FLAG_USE_MAPPABLE){constbool coherentmem-property_flagsVK_MEMORY_PROPERTY_HOST_COHERENT_BIT;constbool cachedmem-property_flagsVK_MEMORY_PROPERTY_HOST_CACHED_BIT;map_info(coherentcached)?VIRGL_RENDERER_MAP_CACHE_CACHED:VIRGL_RENDERER_MAP_CACHE_WC;}这个字段随后被存进virgl_resourcevirglrenderer.c 的res-map_info blob.map_info在MAP_BLOB时回传给 guest最终决定 guest 那段 BAR 的 PAT 设置以及 hypervisor 二级页表里的 memory type。一个 32 位的小字段纵贯后端 → 核心 → VMM → guest → 硬件页表五个环节。它是第 10 篇“缓存一致性陷阱”的主角这里先埋下伏笔。5、本篇小结与下一站这一篇我们打通了“host 内存如何出现在 guest”这条关键链路host-visible 内存区是 guest 物理地址空间里预留的“公共停车场”映射 blob 就是往里停车、拿车位号offset创建与映射分离是刻意设计存储长期存在窗口按需复用生命周期解耦RESOURCE_MAP_BLOB / UNMAP_BLOB是 guest 主动驱动映射的命令map_info携带缓存语义纵贯五层任何一环不一致都会出问题。下一篇第 5 篇我们离开规范层进入Guest 侧内核。看看drivers/gpu/drm/virtio到底怎么把 Mesa 的一次内存申请变成上面这些命令塞进 virtqueue。导航上一篇第 3 篇 blob 的三维输入模型blob_mem × blob_flags × blob_id下一篇[第 5 篇 guest 内核 virtio-gpu 驱动如何发起 blob]审核中…