第三篇讨论了 virtqueue。本篇继续补上另一半：virtqueue 只是共享内存，guest 和 QEMU 如何知道对方有新请求或完成事件？这就是 notification、eventfd、irqfd 和中断注入要解决的问题。

1. 为什么 virtqueue 还需要通知

virtqueue 解决的是数据放在哪里。

Guest driver 把 descriptor 写到 guest memory，QEMU 或 backend 从 guest memory 读取 descriptor。

但共享内存本身不会告诉对方“我写好了”。

所以 virtio 还需要通知机制：

Guest -> Host: 我提交了新的 descriptor，请处理。 Host -> Guest: 我完成了请求，请回收。

没有通知，双方只能不断轮询 queue index。

轮询可以降低延迟，但会消耗 CPU；中断和 eventfd 可以减少空转，但有唤醒和注入成本。

virtio 性能优化很大一部分，就是在通知次数、批量处理和延迟之间做平衡。

2. 基本通知路径

一次普通请求的通知路径可以写成：

Guest submits descriptors | | kick v QEMU / backend wakes up | | process virtqueue v write used ring | | interrupt / notify v Guest driver handles completion

这里有两个方向：

kick: guest 通知 device 有新请求 interrupt: device 通知 guest 请求完成

不同 transport 和不同加速路径会影响这两个方向的实现。

3. guest 如何 kick QEMU

在 virtio-mmio 中，guest 通常通过写 MMIO notify register 来通知 device。

在 virtio-pci 中，guest 可能通过 PCI BAR 中的 queue notify 区域通知 device。

抽象模型：

Guest driver updates avail ring | v Guest writes notify register | v VM exit or ioeventfd path | v QEMU / backend receives kick

如果没有加速，每次 notify register 写入可能导致 VM exit 到 QEMU，由 QEMU 处理这次 kick。

为了减少这类高频 exit，QEMU/KVM 可以使用 ioeventfd。

4. eventfd 的直觉

eventfd 是 Linux 提供的一种轻量事件通知机制。

在 QEMU/KVM/virtio 路径中，可以把 eventfd 理解成一个“可被内核和用户态共同使用的事件计数器”。

对于 guest -> host kick，QEMU 可以把某个 MMIO/PIO 写通知注册给 KVM。

当 guest 写对应 notify 地址时，KVM 不必返回 QEMU 处理完整 MMIO exit，而是直接 signal 一个 eventfd。

简化模型：

Guest writes virtqueue notify | v KVM detects registered ioeventfd | v signal eventfd | v QEMU or vhost backend wakes and handles queue

这减少了传统 MMIO exit 的开销。

5. QEMU 如何 interrupt guest

请求完成后，QEMU 或 backend 需要通知 guest。

最基本的路径是：

QEMU writes used ring | v QEMU raises virtio interrupt | v KVM injects virtual interrupt | v Guest interrupt handler runs

对于 virtio-mmio，设备中断通常接到虚拟中断控制器。

对于 virtio-pci，可能使用 MSI/MSI-X。

在 KVM 加速场景中，irqfd 可以进一步减少用户态参与。

6. irqfd 的直觉

irqfd 解决的是 host -> guest interrupt 的快速注入问题。

QEMU 可以把一个 eventfd 绑定到某个 guest interrupt。

当 backend signal 这个 eventfd 时，KVM 可以直接向 guest 注入对应中断，而不是让 QEMU 先醒来再调用中断注入接口。

简化模型：

backend completes request | v signal call eventfd | v KVM irqfd path | v inject virtual interrupt | v Guest sees completion interrupt

这在 vhost 场景尤其重要。

因为数据面已经下沉到 kernel 或独立 backend，如果每次 completion 都必须回 QEMU 注入中断，会削弱 vhost 的意义。

7. kick eventfd 与 call eventfd

virtio/vhost 路径里经常会看到两类 eventfd：

kick eventfd: guest 通知 backend：avail ring 有新请求 call eventfd: backend 通知 guest：used ring 有新完成

可以画成：

Guest driver | | kick eventfd v backend processes virtqueue | | call eventfd v Guest interrupt

QEMU 负责创建、配置和传递这些 eventfd。

vhost backend 使用它们实现高效通知。

8. notification suppression

并不是每次提交 descriptor 都必须通知。

也不是每次完成请求都必须中断 guest。

virtio 支持 notification suppression 相关机制，用来减少通知次数。

例如 guest 可以告诉 device：

暂时不要每完成一个请求就中断我。 我稍后会批量检查 used ring。

device 也可以根据 queue 状态决定是否需要通知 guest。

这类机制的目标是减少：

• VM exit
• eventfd signal
• interrupt injection
• guest interrupt handler 开销
• host/guest 上下文切换

代价是 completion latency 可能上升。

所以高吞吐场景倾向于批量化，高低延迟场景则要更谨慎。

9. QEMU 主循环与 virtqueue 处理

在基础 QEMU device model 路径中，kick 到来后，QEMU 通常会在自己的事件循环或 bottom half 中处理 virtqueue。

简化模型：

event arrives | v QEMU main loop wakes | v schedule virtio device handler | v process available descriptors | v complete requests and notify guest

这说明 QEMU device model 的性能不只取决于 virtqueue 本身，也取决于 QEMU event loop、backend I/O 和通知策略。

10. vhost 场景下的通知路径

使用 vhost 后，通知路径会变成：

Guest driver | | kick eventfd v vhost backend | | process vring directly v call eventfd / irqfd | v Guest interrupt

QEMU 在这里主要做控制面：

• 设置 guest memory table
• 设置 vring address
• 设置 kick/call eventfd
• 启动或停止 vhost backend
• 管理 feature 和 migration

高频数据面不再每次经过 QEMU 主循环。

11. 通知路径中的性能权衡

virtio notification 的核心权衡是：

通知太频繁: 低延迟，但 exit / eventfd / interrupt 开销高 通知太少: 吞吐可能高，但 completion latency 变大

优化手段包括：

• batch descriptor processing
• interrupt coalescing
• notification suppression
• ioeventfd
• irqfd
• vhost
• multiqueue
• polling

不同 workload 目标不同。

数据库、网络转发、块 I/O、低延迟 RPC，对通知策略的需求并不一样。

12. 源码阅读入口

本篇可以看：

• hw/virtio/virtio.c
• hw/virtio/virtio-mmio.c
• hw/virtio/virtio-pci.c
• hw/virtio/vhost.c
• hw/virtio/vhost-user.c
• include/hw/virtio/virtio.h
• include/hw/virtio/vhost.h

阅读问题：

• guest notify 最终调用到哪里？
• VirtQueue的 handler 在哪里被触发？
• used ring 写回后如何决定是否通知 guest？
• eventfd 在哪里创建和绑定？
• irqfd 在哪里接入 KVM？
• vhost 的 kick/call fd 如何配置？

13. 本篇小结

virtqueue 只是共享内存结构，notification 负责让双方知道“该看队列了”。

Guest 通过 kick 通知 host 有新 descriptor；QEMU 或 backend 完成请求后，通过 used ring 和 interrupt 通知 guest。

eventfd、ioeventfd 和 irqfd 的作用，是减少高频通知路径上的用户态往返和不必要 VM exit。

可以把本篇压缩成一句话：

virtio 的数据在 virtqueue 里流动，时机由 notification 驱动；eventfd 和 irqfd 则把这些通知尽量变成轻量、可批量、可下沉的数据面事件。

14. 下一篇预告：virtio-mmio 与 virtio-pci transport

下一篇讨论 transport。

会回答：

• virtio 协议和 transport 的区别是什么？
• RISC-Vvirtmachine 为什么常见 virtio-mmio？
• virtio-pci 如何暴露设备？
• transport 如何连接 guest driver 和VirtIODevice？

下一篇的问题可以写成：

同样是 virtio 设备，guest 到底是通过什么“总线外观”发现和配置它的？