前面的文章以Type-1型的Acrn hypervisor为例，简要介绍了virtio的基础机制。作为para virtualization一个事实上的通用标准，其具体的应用包括块设备、网络设备，以及文件系统等的虚拟化实现。本文将结合基于x86体系的QEMU-KVM，来讲解virtio在网卡虚拟化方面的几种实现方式。
在virtio协议中，host端提供对设备的emulation，guest端负责对设备的驱动，host和guest的关系就是device和driver的关系。我们通常使用读写寄存器的方式，来实现对physical device的控制和驱动，但对于virtio中的emulated device，使用的则是以virtqueue形式组织的内存。
这是因为以寄存器形式访问物理设备是很快速的，使用内存的话还需要DMA的传输，但emulated device不同，它本身就是内存中的一块区域，一板一眼地模拟物理设备的寄存器反倒低效而麻烦。
当guest中的driver试图访问host中的device时，会通过一定的方式触发vm-exit，从non-root模式的ring 0/3切换到root模式的ring 0，即从guest kernel“陷”入host kernel。如果host kernel不能对这个设备进行emulate，就转给host上的userspace（root模式的ring 3）。
用户态实现的Vhost-User
具体到virtio中的网络设备，guest端的driver被称作"virtio-net"，而在host端，早期的经典实现是使用功能丰富的QEMU，即由host端的用户态程序来提供设备的emulation，称为"vhost-user"。
【ioeventfd】
当guest向virtqueue上写入数据完成后，需要通知host端来获取这部分数据（术语叫"kick"），通知的方式是访问一段设定的MMIO区域（但没有真正分配内存），以触发EPT violation/misconfig（类似于page fault），进而形成vm-exit，这种vm-exit会交由host上的KVM内核模块负责处理。
KVM在这里相当于一个代理，它需要进一步通知到用户态的QEMU，为了减小开销，采用的notify方式是相对轻量级的"eventfd"。eventfd可理解为把一个事件抽象为文件（不要和epoll搞混了），其本质上是一个wait queue，因此可用做进程间的通信和同步。
struct eventfd_ctx {
wait_queue_head_t wqh;__u64 count;
}
