QEMU virtio-pmem 持久内存设备详解基于普通存储的虚拟持久内存方案【免费下载链接】qemuOfficial QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are disabled. Please only use release tarballs from the QEMU website.项目地址: https://gitcode.com/gh_mirrors/qe/qemuvirtio-pmem 是 QEMU 提供的半虚拟化paravirtualized持久内存设备可在普通非 NVDIMM宿主存储之上为 Guest 提供具备写入持久化语义的内存设备其官方说明位于 virtio-pmem.rst。本文以该文档为主线结合 QEMU 仓库中的设备实现源码virtio-pmem.c、virtio-pmem-pci.c与标准头文件系统讲解 virtio-pmem 的用途、与 NVDIMM 模拟的差异、命令行配置、热插拔操作、数据持久化语义以及已知限制帮助你在没有真实 NVDIMM 硬件的环境下构建具备持久化能力的虚拟内存设备。一、virtio-pmem 是什么在普通存储上实现持久内存virtio pmem 设备是一种构建在常规即非 NVDIMM存储之上的半虚拟化持久内存设备。它向 Guest 呈现一块可当作持久内存使用的设备内存区域但底层并不依赖真实的 NVDIMM 硬件而是由宿主上的普通文件/块设备充当后备存储。其核心价值体现在两个方面绕过 Guest 页缓存virtio-pmem 允许 Guest 绕过其自身的页缓存直接使用宿主页缓存。这样可以显著降低 Guest 的内存占用——当宿主面临内存压力时宿主能够对这部分页面做出高效的内存回收决策因为宿主完全清楚哪些页面可以回收而无需经过 Guest 内核的二次页缓存管理。提供写入持久化语义与 NVDIMM 模拟设备不同virtio-pmem 在普通宿主存储上仍能保证 Guest 写入具备持久化语义这一点是 NVDIMM 纯模拟无法做到的。从源码结构看virtio-pmem 在 QEMU 中由两层构成底层设备实现virtio-pmemvirtio-pmem.c类型名TYPE_VIRTIO_PMEM定义于 virtio-pmem.h与 PCI 封装virtio-pmem-pcivirtio-pmem-pci.c后者对应命令行中直接使用的设备名virtio-pmem-pci。PCI 层通过MemoryDeviceClass接口将设备接入系统的内存设备框架负责地址分配、已插拔容量上报与设备信息填充见 virtio-pmem-pci.c。二、virtio-pmem 与 NVDIMM 模拟的对比QEMU 也支持在普通宿主存储上模拟 NVDIMM 设备即nvdimm内存设备。两者在持久性上的差异是选型的关键维度NVDIMM 模拟virtio-pmem宿主存储普通非 NVDIMM存储普通非 NVDIMM存储Guest 写入持久性不持久设备规范中未定义普通存储上的持久化语义Guest 写入不会持久化到宿主后备文件持久通过设备语义保证 Guest 写入具备持久化能力页缓存模型常规绕过 Guest 页缓存直接使用宿主页缓存所需硬件无无正是由于 NVDIMM 模拟在普通存储上不持久virtio-pmem 才作为补充方案出现当你的工作负载需要断电后数据仍在的持久内存语义但又没有真实 NVDIMM 硬件时virtio-pmem 是可行的替代路径。在实现层面virtio-pmem 的配置空间结构体仅包含两个字段见 include/standard-headers/linux/virtio_pmem.hstruct virtio_pmem_config { uint64_t start; /* 设备内存区域的 Guest 物理起始地址 */ uint64_t size; /* 设备内存区域的大小 */ };该结构体与 QEMU 侧的virtio_pmem_get_config()回调一一对应virtio-pmem.c后者将设备记录的起始地址与后备 memory region 的大小写入配置空间供 Guest 驱动读取。三、命令行创建 virtio-pmem 设备virtio-pmem 设备由memory-backend-file对象提供后端存储。在 QEMU 命令行上的最小创建示例如下源自 virtio-pmem.rst-object memory-backend-file,idmem1,share,mem-path./virtio_pmem.img,size4G -device virtio-pmem-pci,memdevmem1,idnv1逐项拆解-object memory-backend-file,idmem1,share,mem-pathimage,sizeimage size创建一个以文件为后备的内存后端对象。idmem1对象标识符供后续-device引用share等价于shareon以共享映射方式打开后端修改会写回后备文件——对持久内存语义至关重要mem-path./virtio_pmem.img后备文件路径建议预先创建好指定大小的镜像文件size4G后端内存大小即持久内存设备的容量需与镜像文件大小匹配。-device virtio-pmem-pci,idnv1,memdevmem1创建 virtio-pmem 的 PCI 设备实例其存储由上面的内存后端对象提供。memdev属性即源码中的VIRTIO_PMEM_MEMDEV_PROPid为设备在 QEMU 中的标识。在设备实现中这两个属性被声明为设备属性virtio-pmem.cstatic const Property virtio_pmem_properties[] { DEFINE_PROP_UINT64(VIRTIO_PMEM_ADDR_PROP, VirtIOPMEM, start, 0), DEFINE_PROP_LINK(VIRTIO_PMEM_MEMDEV_PROP, VirtIOPMEM, memdev, TYPE_MEMORY_BACKEND, HostMemoryBackend *), };其中memdev必须是TYPE_MEMORY_BACKEND类型如memory-backend-filememaddr即start通常由内存设备框架自动分配一般无需手动指定。设备在 realize 阶段会校验memdev是否已设置、是否已被其他设备占用随后把后端标记为已映射host_memory_backend_set_mapped并注册一个深度为 128 的请求队列rq_vqvirtio-pmem.c。关于share选项的底层含义可参考 backends/hostmem-file.cshare会决定后端使用RAM_SHARED还是RAM_PRIVATE标志映射而is_pmem属性则会额外叠加RAM_PMEM标志。对 virtio-pmem 而言shareon是保证数据能落回宿主后备文件的必要前提。多设备如果提供多组-object与-device配对就可以在同一个 Guest 中创建多个 virtio-pmem 设备例如再追加一个 8G 设备-object memory-backend-file,idmem3,share,mem-path./virtio_pmem3.img,size8G -device virtio-pmem-pci,memdevmem3,idnv3完整启动示例以 x86_64 架构为例其它架构请替换对应的 QEMU 二进制名qemu-system-x86_64 -m 4G \ -object memory-backend-file,idmem1,share,mem-path./virtio_pmem.img,size4G \ -device virtio-pmem-pci,memdevmem1,idnv1 \ -drive fileguest.qcow2,ifvirtio \ -nographic四、通过 QEMU monitor 热插拔 virtio-pmemvirtio-pmem 支持在运行时通过 QEMU monitor 热插拔hotplug操作分两步先添加内存后端对象再添加设备。以下命令为运行中的 Guest 追加一块 4GB 的 virtio-pmem源自 virtio-pmem.rst(qemu) object_add memory-backend-file,idmem2,shareon,mem-pathvirtio_pmem2.img,size4G (qemu) device_add virtio-pmem-pci,idvirtio_pmem2,memdevmem2要点object_add的参数与命令行-object一致注意这里显式写作shareondevice_add中id与memdev必须对应若未指定id设备仍会创建但后续难以通过 QMP/HMP 精确定位若希望回滚热插拔操作可通过device_del移除设备、object_del删除后端对象。但请注意virtio-pmem 不支持热拔hotunplug详见下文限制一节device_del能否成功取决于具体版本与驱动行为官方文档并未将其列为支持能力。从代码角度看PCI 封装层实现了完整的MemoryDeviceClass接口virtio-pmem-pci.cget_addr/set_addr负责读写设备的memaddr属性以分配 Guest 物理地址get_plugged_size返回 memory region 的实际大小作为已插拔容量get_memory_region返回后端 memory regionfill_device_info则把设备信息填充为 QMP 的MemoryDeviceInfo类型为virtio-pmem见 qapi/machine.json。正是这套接口让 virtio-pmem 能够无缝融入 QEMU 的内存设备热插拔框架。五、Guest 侧数据持久化fsync/msync 语义在普通非 NVDIMM宿主存储上Guest 数据要真正持久化必须由Guest 用户态应用程序主动执行fsync/msync系统调用。这与真实 NVDIMM 后端不同——真实 NVDIMM 后端无需额外的 fsync/msync 即可持久化。原因在于若不显式刷盘Guest 的写入只会停留在宿主页缓存中一旦宿主断电这部分数据就会丢失。因此 virtio-pmem 的持久化语义是显式刷盘模型应用程序负责在关键数据点调用 fsync/msync把数据从宿主页缓存刷入后备文件。设备规范层面virtio-pmem不支持MAP_SYNCmmap 标志。这是一个刻意的设计选择由于设备不提供 MAP_SYNC应用程序无法通过 mmap 隐式获得持久化保证从而被提示必须显式调用 fsync 来保证写入持久化见 virtio-pmem.rst。在 QEMU 实现中Guest 驱动通过virtio_pmem_req结构提交请求include/standard-headers/linux/virtio_pmem.h#define VIRTIO_PMEM_REQ_TYPE_FLUSH 0 /* 唯一支持的请求类型刷盘 */ struct virtio_pmem_resp { uint32_t ret; /* 宿主返回的刷盘状态 */ }; struct virtio_pmem_req { uint32_t type; /* 命令类型 */ };设备端收到请求后会把请求提交到线程池在后台工作线程中对后端文件执行fsync()virtio-pmem.cstatic int worker_cb(void *opaque) { VirtIODeviceRequest *req_data opaque; int err 0; /* flush raw backing image */ err fsync(req_data-fd); ... }可以看到fsync的目标文件描述符来自后端 memory regionreq_data-fd memory_region_get_fd(backend-mr)virtio-pmem.c。换言之Guest 每次发出 FLUSH 请求QEMU 都会把整个后端文件刷盘一次从而将页缓存中的脏页落盘。请求完成后通过done_cb将响应写回 virtqueue 并通知 Guestvirtio-pmem.c期间用inflight计数跟踪在途请求设备销毁时会等待所有在途刷盘完成AIO_WAIT_WHILE见 virtio-pmem.c。这套 FLUSH 机制在 QEMU 的 trace 事件中也有完整埋点见 hw/virtio/trace-events包括请求、刷盘完成与响应三个阶段的跟踪点便于开发者排查刷盘路径上的性能与正确性问题。六、限制与注意事项官方文档明确列出了 virtio-pmem 当前的能力边界见 virtio-pmem.rst不支持真实 NVDIMM 设备后端virtio-pmem 只面向普通存储后端无法直接挂在物理 NVDIMM 设备上不支持 virtio-pmem 热拔hotunplug设备创建后无法从运行中的 Guest 卸载不支持 ACPI NVDIMM 特性例如 NVDIMM 的 region、namespace 等管理能力在 virtio-pmem 上不可用不支持 ndctl 命令由于没有 NVDIMM namespace 模型Linux 的ndctl工具无法管理 virtio-pmem 设备Guest 内应通过 /dev/pmemX 块设备路径直接使用。七、在 Guest 内使用 virtio-pmemGuest 侧以 Linux 为例完成 virtio-pmem 设备配置后设备在 Guest 内以块设备形式出现通常为/dev/pmem0因为 virtio-pmem 的驱动模型是内存设备 块设备入口可直接对其创建文件系统例如mkfs.ext4 /dev/pmem0 mount /dev/pmem0 /mnt/pmem应用层写入数据后如需持久化必须显式调用fsync对文件或msync对 mmap 区域否则数据可能仅存于宿主页缓存宿主断电时会丢失由于不支持 ndctl/namespace不要尝试用ndctl create-namespace之类的命令管理该设备。八、总结virtio-pmem 是 QEMU 在无 NVDIMM 硬件环境下提供可持久化的虚拟内存设备的关键手段它通过memory-backend-file将普通文件映射为设备内存绕过 Guest 页缓存以降低内存占用并以Guest 显式 fsync/msync QEMU 后台 fsync 落盘的方式在普通存储上实现写入持久化。理解其 FLUSH 请求的完整链路Guest 请求 → virtqueue → 线程池 worker 的fsync→ 响应回传与不支持热拔、不支持 ndctl/namespace的能力边界是在生产环境正确选型与使用 virtio-pmem 的前提。进一步阅读设备实现hw/virtio/virtio-pmem.c、hw/virtio/virtio-pmem-pci.c设备头文件include/hw/virtio/virtio-pmem.h规范结构体include/standard-headers/linux/virtio_pmem.hQMP 设备信息qapi/machine.json相关文档索引docs/system/devices/virtio/index.rst【免费下载链接】qemuOfficial QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are disabled. Please only use release tarballs from the QEMU website.项目地址: https://gitcode.com/gh_mirrors/qe/qemu创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
QEMU virtio-pmem 持久内存设备详解基于普通存储的虚拟持久内存方案【免费下载链接】qemuOfficial QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are disabled. Please only use release tarballs from the QEMU website.项目地址: https://gitcode.com/gh_mirrors/qe/qemuvirtio-pmem 是 QEMU 提供的半虚拟化paravirtualized持久内存设备可在普通非 NVDIMM宿主存储之上为 Guest 提供具备写入持久化语义的内存设备其官方说明位于 virtio-pmem.rst。本文以该文档为主线结合 QEMU 仓库中的设备实现源码virtio-pmem.c、virtio-pmem-pci.c与标准头文件系统讲解 virtio-pmem 的用途、与 NVDIMM 模拟的差异、命令行配置、热插拔操作、数据持久化语义以及已知限制帮助你在没有真实 NVDIMM 硬件的环境下构建具备持久化能力的虚拟内存设备。一、virtio-pmem 是什么在普通存储上实现持久内存virtio pmem 设备是一种构建在常规即非 NVDIMM存储之上的半虚拟化持久内存设备。它向 Guest 呈现一块可当作持久内存使用的设备内存区域但底层并不依赖真实的 NVDIMM 硬件而是由宿主上的普通文件/块设备充当后备存储。其核心价值体现在两个方面绕过 Guest 页缓存virtio-pmem 允许 Guest 绕过其自身的页缓存直接使用宿主页缓存。这样可以显著降低 Guest 的内存占用——当宿主面临内存压力时宿主能够对这部分页面做出高效的内存回收决策因为宿主完全清楚哪些页面可以回收而无需经过 Guest 内核的二次页缓存管理。提供写入持久化语义与 NVDIMM 模拟设备不同virtio-pmem 在普通宿主存储上仍能保证 Guest 写入具备持久化语义这一点是 NVDIMM 纯模拟无法做到的。从源码结构看virtio-pmem 在 QEMU 中由两层构成底层设备实现virtio-pmemvirtio-pmem.c类型名TYPE_VIRTIO_PMEM定义于 virtio-pmem.h与 PCI 封装virtio-pmem-pcivirtio-pmem-pci.c后者对应命令行中直接使用的设备名virtio-pmem-pci。PCI 层通过MemoryDeviceClass接口将设备接入系统的内存设备框架负责地址分配、已插拔容量上报与设备信息填充见 virtio-pmem-pci.c。二、virtio-pmem 与 NVDIMM 模拟的对比QEMU 也支持在普通宿主存储上模拟 NVDIMM 设备即nvdimm内存设备。两者在持久性上的差异是选型的关键维度NVDIMM 模拟virtio-pmem宿主存储普通非 NVDIMM存储普通非 NVDIMM存储Guest 写入持久性不持久设备规范中未定义普通存储上的持久化语义Guest 写入不会持久化到宿主后备文件持久通过设备语义保证 Guest 写入具备持久化能力页缓存模型常规绕过 Guest 页缓存直接使用宿主页缓存所需硬件无无正是由于 NVDIMM 模拟在普通存储上不持久virtio-pmem 才作为补充方案出现当你的工作负载需要断电后数据仍在的持久内存语义但又没有真实 NVDIMM 硬件时virtio-pmem 是可行的替代路径。在实现层面virtio-pmem 的配置空间结构体仅包含两个字段见 include/standard-headers/linux/virtio_pmem.hstruct virtio_pmem_config { uint64_t start; /* 设备内存区域的 Guest 物理起始地址 */ uint64_t size; /* 设备内存区域的大小 */ };该结构体与 QEMU 侧的virtio_pmem_get_config()回调一一对应virtio-pmem.c后者将设备记录的起始地址与后备 memory region 的大小写入配置空间供 Guest 驱动读取。三、命令行创建 virtio-pmem 设备virtio-pmem 设备由memory-backend-file对象提供后端存储。在 QEMU 命令行上的最小创建示例如下源自 virtio-pmem.rst-object memory-backend-file,idmem1,share,mem-path./virtio_pmem.img,size4G -device virtio-pmem-pci,memdevmem1,idnv1逐项拆解-object memory-backend-file,idmem1,share,mem-pathimage,sizeimage size创建一个以文件为后备的内存后端对象。idmem1对象标识符供后续-device引用share等价于shareon以共享映射方式打开后端修改会写回后备文件——对持久内存语义至关重要mem-path./virtio_pmem.img后备文件路径建议预先创建好指定大小的镜像文件size4G后端内存大小即持久内存设备的容量需与镜像文件大小匹配。-device virtio-pmem-pci,idnv1,memdevmem1创建 virtio-pmem 的 PCI 设备实例其存储由上面的内存后端对象提供。memdev属性即源码中的VIRTIO_PMEM_MEMDEV_PROPid为设备在 QEMU 中的标识。在设备实现中这两个属性被声明为设备属性virtio-pmem.cstatic const Property virtio_pmem_properties[] { DEFINE_PROP_UINT64(VIRTIO_PMEM_ADDR_PROP, VirtIOPMEM, start, 0), DEFINE_PROP_LINK(VIRTIO_PMEM_MEMDEV_PROP, VirtIOPMEM, memdev, TYPE_MEMORY_BACKEND, HostMemoryBackend *), };其中memdev必须是TYPE_MEMORY_BACKEND类型如memory-backend-filememaddr即start通常由内存设备框架自动分配一般无需手动指定。设备在 realize 阶段会校验memdev是否已设置、是否已被其他设备占用随后把后端标记为已映射host_memory_backend_set_mapped并注册一个深度为 128 的请求队列rq_vqvirtio-pmem.c。关于share选项的底层含义可参考 backends/hostmem-file.cshare会决定后端使用RAM_SHARED还是RAM_PRIVATE标志映射而is_pmem属性则会额外叠加RAM_PMEM标志。对 virtio-pmem 而言shareon是保证数据能落回宿主后备文件的必要前提。多设备如果提供多组-object与-device配对就可以在同一个 Guest 中创建多个 virtio-pmem 设备例如再追加一个 8G 设备-object memory-backend-file,idmem3,share,mem-path./virtio_pmem3.img,size8G -device virtio-pmem-pci,memdevmem3,idnv3完整启动示例以 x86_64 架构为例其它架构请替换对应的 QEMU 二进制名qemu-system-x86_64 -m 4G \ -object memory-backend-file,idmem1,share,mem-path./virtio_pmem.img,size4G \ -device virtio-pmem-pci,memdevmem1,idnv1 \ -drive fileguest.qcow2,ifvirtio \ -nographic四、通过 QEMU monitor 热插拔 virtio-pmemvirtio-pmem 支持在运行时通过 QEMU monitor 热插拔hotplug操作分两步先添加内存后端对象再添加设备。以下命令为运行中的 Guest 追加一块 4GB 的 virtio-pmem源自 virtio-pmem.rst(qemu) object_add memory-backend-file,idmem2,shareon,mem-pathvirtio_pmem2.img,size4G (qemu) device_add virtio-pmem-pci,idvirtio_pmem2,memdevmem2要点object_add的参数与命令行-object一致注意这里显式写作shareondevice_add中id与memdev必须对应若未指定id设备仍会创建但后续难以通过 QMP/HMP 精确定位若希望回滚热插拔操作可通过device_del移除设备、object_del删除后端对象。但请注意virtio-pmem 不支持热拔hotunplug详见下文限制一节device_del能否成功取决于具体版本与驱动行为官方文档并未将其列为支持能力。从代码角度看PCI 封装层实现了完整的MemoryDeviceClass接口virtio-pmem-pci.cget_addr/set_addr负责读写设备的memaddr属性以分配 Guest 物理地址get_plugged_size返回 memory region 的实际大小作为已插拔容量get_memory_region返回后端 memory regionfill_device_info则把设备信息填充为 QMP 的MemoryDeviceInfo类型为virtio-pmem见 qapi/machine.json。正是这套接口让 virtio-pmem 能够无缝融入 QEMU 的内存设备热插拔框架。五、Guest 侧数据持久化fsync/msync 语义在普通非 NVDIMM宿主存储上Guest 数据要真正持久化必须由Guest 用户态应用程序主动执行fsync/msync系统调用。这与真实 NVDIMM 后端不同——真实 NVDIMM 后端无需额外的 fsync/msync 即可持久化。原因在于若不显式刷盘Guest 的写入只会停留在宿主页缓存中一旦宿主断电这部分数据就会丢失。因此 virtio-pmem 的持久化语义是显式刷盘模型应用程序负责在关键数据点调用 fsync/msync把数据从宿主页缓存刷入后备文件。设备规范层面virtio-pmem不支持MAP_SYNCmmap 标志。这是一个刻意的设计选择由于设备不提供 MAP_SYNC应用程序无法通过 mmap 隐式获得持久化保证从而被提示必须显式调用 fsync 来保证写入持久化见 virtio-pmem.rst。在 QEMU 实现中Guest 驱动通过virtio_pmem_req结构提交请求include/standard-headers/linux/virtio_pmem.h#define VIRTIO_PMEM_REQ_TYPE_FLUSH 0 /* 唯一支持的请求类型刷盘 */ struct virtio_pmem_resp { uint32_t ret; /* 宿主返回的刷盘状态 */ }; struct virtio_pmem_req { uint32_t type; /* 命令类型 */ };设备端收到请求后会把请求提交到线程池在后台工作线程中对后端文件执行fsync()virtio-pmem.cstatic int worker_cb(void *opaque) { VirtIODeviceRequest *req_data opaque; int err 0; /* flush raw backing image */ err fsync(req_data-fd); ... }可以看到fsync的目标文件描述符来自后端 memory regionreq_data-fd memory_region_get_fd(backend-mr)virtio-pmem.c。换言之Guest 每次发出 FLUSH 请求QEMU 都会把整个后端文件刷盘一次从而将页缓存中的脏页落盘。请求完成后通过done_cb将响应写回 virtqueue 并通知 Guestvirtio-pmem.c期间用inflight计数跟踪在途请求设备销毁时会等待所有在途刷盘完成AIO_WAIT_WHILE见 virtio-pmem.c。这套 FLUSH 机制在 QEMU 的 trace 事件中也有完整埋点见 hw/virtio/trace-events包括请求、刷盘完成与响应三个阶段的跟踪点便于开发者排查刷盘路径上的性能与正确性问题。六、限制与注意事项官方文档明确列出了 virtio-pmem 当前的能力边界见 virtio-pmem.rst不支持真实 NVDIMM 设备后端virtio-pmem 只面向普通存储后端无法直接挂在物理 NVDIMM 设备上不支持 virtio-pmem 热拔hotunplug设备创建后无法从运行中的 Guest 卸载不支持 ACPI NVDIMM 特性例如 NVDIMM 的 region、namespace 等管理能力在 virtio-pmem 上不可用不支持 ndctl 命令由于没有 NVDIMM namespace 模型Linux 的ndctl工具无法管理 virtio-pmem 设备Guest 内应通过 /dev/pmemX 块设备路径直接使用。七、在 Guest 内使用 virtio-pmemGuest 侧以 Linux 为例完成 virtio-pmem 设备配置后设备在 Guest 内以块设备形式出现通常为/dev/pmem0因为 virtio-pmem 的驱动模型是内存设备 块设备入口可直接对其创建文件系统例如mkfs.ext4 /dev/pmem0 mount /dev/pmem0 /mnt/pmem应用层写入数据后如需持久化必须显式调用fsync对文件或msync对 mmap 区域否则数据可能仅存于宿主页缓存宿主断电时会丢失由于不支持 ndctl/namespace不要尝试用ndctl create-namespace之类的命令管理该设备。八、总结virtio-pmem 是 QEMU 在无 NVDIMM 硬件环境下提供可持久化的虚拟内存设备的关键手段它通过memory-backend-file将普通文件映射为设备内存绕过 Guest 页缓存以降低内存占用并以Guest 显式 fsync/msync QEMU 后台 fsync 落盘的方式在普通存储上实现写入持久化。理解其 FLUSH 请求的完整链路Guest 请求 → virtqueue → 线程池 worker 的fsync→ 响应回传与不支持热拔、不支持 ndctl/namespace的能力边界是在生产环境正确选型与使用 virtio-pmem 的前提。进一步阅读设备实现hw/virtio/virtio-pmem.c、hw/virtio/virtio-pmem-pci.c设备头文件include/hw/virtio/virtio-pmem.h规范结构体include/standard-headers/linux/virtio_pmem.hQMP 设备信息qapi/machine.json相关文档索引docs/system/devices/virtio/index.rst【免费下载链接】qemuOfficial QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are disabled. Please only use release tarballs from the QEMU website.项目地址: https://gitcode.com/gh_mirrors/qe/qemu创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
