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

原创于 2026-09-25 13:45:00 发布 · 245 阅读

6 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

virtio-gpu 虚拟化分析

上一篇我们拆开了 blob_mem × blob_flags × blob_id 三维输入，并留了一个悬念： MAPPABLE 到底意味着什么？host 分配的内存，究竟怎么“出现”在 guest 里？这一篇专门回答它。我们会引出 host-visible 内存区这个容器，以及 RESOURCE_MAP_BLOB / UNMAP_BLOB 这对命令，还有那个纵贯三层、一路要传到 hypervisor 页表的 map_info。

在进入正题之前，先聊聊虚拟化的理想安全模型。在虚拟化世界里，最理想的安全模型是：每个域（虚拟机）之间都无法越权访问对方，最好做到完全互不访问。但这样的理想模型因性能开销太大，根本无法落地到生产环境。因此，必须设计安全的域间互访机制——安全与互访，由此成为虚拟化设计中的一对矛盾，也正是虚拟化最有趣、最有魅力的地方。从整个角度来看，我们这个专栏讲的就是存储资源的域间互访。好，言归正传。

1、核心难题：两个地址空间如何“对齐”

回顾一下矛盾的本质：

guest 应用只认识 guest 物理地址（GPA）；
host 分配的 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，用 shmid VIRTIO_GPU_SHM_ID_HOST_VISIBLE 标识。它在 guest 眼里就是设备 BAR 上的一大段物理地址空间。

你可以把它想象成一个公共停车场：

停车场本身（整段 region）在虚拟机启动时就规划好了，占据一段固定的 GPA 范围；
每一个被映射的 blob，就是停进去的一辆车，占据停车场里的一个 offset + 大小；
guest 拿到的“车位号”，就是这个 offset —— 它据此算出 GPA，然后就能直接读写。

这个设计的妙处在于：guest 物理地址空间的窗口是预留好的、固定的，映射 blob 只是往窗口里“填内容”，不需要每次都重新协商 guest 的地址布局。

3、创建与映射：为什么是分离的两步

第 2 篇我们强调过：“创建 blob”和“映射 blob”是两条独立的命令。现在可以讲清为什么这样设计了。

RESOURCE_CREATE_BLOB：只负责搞到一块 host 存储（后端分配、导出 fd）。这一步的产物是一个 fd，被 VMM 记在资源表里，但还没进 guest 地址空间。
RESOURCE_MAP_BLOB：guest 显式请求“现在把这个资源映射进 host-visible region”。VMM 才真正 mmap 那个 fd，并在停车场里分配 offset。
RESOURCE_UNMAP_BLOB：反过来，把车开走，释放 offset，撤销映射。

分离的好处：

不是每个 blob 都需要映射。很多 blob 只在 host 侧被 GPU 使用（比如中间渲染目标），guest CPU 根本不看，那就永远不必占用宝贵的 region 窗口。
窗口是稀缺资源，可以按需 map / unmap 复用，而存储本身（fd）可以长期存在。
生命周期解耦：存储的所有权（谁关 fd）和映射的生命周期（谁 unmap）是两码事，可以分别管理。

4、map_info：一路传到硬件页表的缓存属性

映射不仅仅是“地址对上”，还得缓存属性对上。同一块物理内存，如果 host 端按 write-combining（WC）访问、guest 端却按 write-back（WB）缓存，就会出现脏数据、花屏、乱序可见等一致性灾难。

map_info 就是携带这条缓存语义的字段。它的取值（在 virglrenderer 里）大致是：

VIRGL_RENDERER_MAP_CACHE_CACHED（WB，可缓存）
VIRGL_RENDERER_MAP_CACHE_WC（write-combining）
VIRGL_RENDERER_MAP_CACHE_NONE（不缓存 / 未指定）

它的来历，在 venus 后端里看得很清楚（vkr_device_memory.c）——由 Vulkan 内存的属性推导：

if (blob_flags & VIRGL_RENDERER_BLOB_FLAG_USE_MAPPABLE) {
    const bool coherent = mem->property_flags & VK_MEMORY_PROPERTY_HOST_COHERENT_BIT;
    const bool cached   = mem->property_flags & VK_MEMORY_PROPERTY_HOST_CACHED_BIT;
    map_info = (coherent && cached) ? VIRGL_RENDERER_MAP_CACHE_CACHED
                                    : VIRGL_RENDERER_MAP_CACHE_WC;
}

这个字段随后被存进 virgl_resource（virglrenderer.c 的 res->map_info = blob.map_info），在 MAP_BLOB 时回传给 guest，最终决定 guest 那段 BAR 的 PAT 设置，以及 hypervisor 二级页表里的 memory type。