LWN: 把virtio变成真实设备！

关注了就能看到更多这么棒的文章哦～

Virtio without the "virt"

November 22, 2019

This article was contributed by Stefan Hajnoczi and Michael Tsirkin

---

KVM Forum

原文链接：https://lwn.net/Articles/805235/

在virtio功能合入Linux v2.6.24的时候，它的作者Rusty Russel介绍目标是成为“一个能供大多数虚拟I/O机制所用的公共驱动”。目前virtio确实已经在这个方向取得了很多进展，有很多种hypervisor和多种操作系统里的guest驱动都支持virtio。不过这些virtio的应用都是完全用软件实现的，而Michael Tsirkin在KVM Forum 2019上名为“VirtIO without the Virt”的演讲则讲述了如何用硬件实现virtio。

Motivation

大家可能会想，为什么需要用硬件来实现virtio设备？virtio起初是针对hypervisor来设计的，设计中也是针对软件实现方式来做的优化，而不是针对硬件。现在virtio已经广泛传播开来，因此这个网络效应就引发了一些重用这个guest驱动和基础设施的硬件实现。在virtio 1.1 specification里面定义了10个设备类型，包括网络接口，SCSI host bus adapter适配器，以及console。如果能实现出符合这些标准的硬件，这样硬件供应商就能专注于构造最好的设备本身，而不用分心去设计一套新的设备接口、重写一套guest驱动程序。不仅如此，目前的guest系统还能直接用上这套新硬件，相应的应用程序（例如DPDK这样的packet处理工具包）也能跟user-space驱动配合好，而不需要跟新创建的驱动再适配一次了，尤其是在用了静态链接方式的情况格外有好处。

用硬件方式来实现virtio也有助于在硬件和软件方案中来回切换。软件实现的设备可以在不需要更改guest驱动的情况下就替换为硬件方案。类似地，如果驱动已经可用了，也可以把硬件替换成软件设备来帮助调试这个驱动。运行起来之后，我们可以对那些要求高性能的guest系统分配硬件设备，而针对其他guest系统则分配软件设备。相关的决策还可以随时更改来更好地平衡资源适用情况。最后，用硬件来实现virtio还能更容易地支持对虚拟机进行热迁移（live-migrate），目标host系统无论是有软件的还是硬件的virtio设备都可以支持迁移过来的guest系统了。

Implementing virtio PCI devices

virtio对硬件提供商来说有很多有用属性。许多设备类型都有一些可选功能，在实现这个设备的时候就可以只挑选一个子集来满足相应的使用场景即可。这些可选项会在设备初始化的时候协商确认出来，从而确保向后向前兼容。这也意味着硬件设备就可以在今后新版本的virtio规范广泛应用之后仍能跟geust驱动配合工作。老版本的guest驱动也同样能跟新版本的设备配合好。

virtio的历史决定了它是针对软件实现方式进行性能优化的。它会利用guest的物理地址而不是使用还要经过IOMMU翻译的PCI总线地址。内存一致性问题也未考虑过，DMA的memory-ordering原语就根本不需要。在准备做硬件实现virtio的时候，在virtio 1.1里增加了两个feature bit：VIRTIO_F_ORDER_PLATFORM和VIRTIO_F_ACCESS_PLATFORM。如果某个设备宣称自己具有这两个功能的话，驱动就需要使用总线地址和DMA memory ordering原语。

在硬件实现virtio PCI设备时至少有三种方法：full offloading，virtual data path acceleration (vDPA)，还有vDPA partitioning。其中full offloading会把整个设备或者其中的一个PCI SR-IOV 虚拟功能（VF，就是PCI适配器上的一个方便虚拟化场景使用的子设备）传递给guest。所有的设备访问都是由硬件来处理了，包括设备初始化，还有数据通路设备操作。在这种方式下，所有软件都是跟vendor无关的，可以通用。

相应的，vDPA则是一个软硬件混合的方案，其中会有vendor提供的一个驱动程序来截获virtio驱动发起的针对控制通路（设备的发现、初始化）的访问，利用软件来处理这些请求。而数据通路则是由硬件按照virtio规范来实现的。性能也很好，因为数据通路是由硬件来直接处理的。

最后一类vDPA partition会在guest之间进行更细粒度的内存保护，例如PCI process address space ID (PASID)就会提供多个（而不是一个）虚拟地址空间供设备访问。这样就可以对资源进行弹性更好地分配管理，因为用户能随意配置host驱动来把资源传递给guest。PASID功能还没有怎么用起来，因此这个方向的探索比起其他两项要少很多。

Live migration

用户经常希望把一个正在运行的guest系统迁移到另外一个host上，并且暂停服务的时间要尽量少。在有硬件设备传递给guest的时候，这个工作就很难做了，因为多数硬件设备还不支持保存、恢复设备状态。virtio 1.1规范里面也没有详细规定这一部分，因此硬件提供商还只能自己来小心处理。

QEMU在做live-migration的时候会把virtio的feature bit中规定要由host来提供的功能，在新的host上也先分配、锁定相应的资源。这样一来热迁移的时候就能确保guest所依赖的功能已经具备好了。假如迁移目标host上的硬件设备并不支持这些需要用到的feature bit，那么就没法进行迁移了。

在热迁移进行过程中，需要记录对guest RAM的write操作，因为RAM的增量迁移进行的同时，原来的host上运行的这个guest仍然在运行中。如果有一些write操作被丢失了，目标host收到的guest RAM内容就是一个过期、不完备的一份备份。硬件设备需要能参与到这个记录write操作的工程中来。计划在今后的VFIO mediated device (mdev)驱动子系统中会增加相应的框架代码来进行支持。

在将来，随着IOMMU的广泛应用，无论是vendor无关的热迁移功能，还是消除memory pinning，应该都可能成为现实。Linux和相应的IOMMU硬件里面新增的shared virtual addressing (SVA，公共虚拟寻址)都可以允许设备在不使用专门的IOMMU page table的情况下访问到一个进程的地址空间。unpinned memory则更有吸引力一些，因为这样就能支持page swap以及memory overcommit了。此外，这样也能让热迁移过程中的write操作记录的工作更加简单，因为设备写入内存的时候就会触发fault从而就能不依赖vendor而记录下来。

PCI page request interface (PRI)就是允许IOMMU fault处理的一个机制，不过它要支持post-copy live migration还是不够的，这种情况下guest需要马上就在目标host上运行起来、而不先进行guest RAM的迁移。在post-copy live migration场景中，旧的host上的guest RAM进入fault之后不确定花多长时间才能处理完比，这种对PRI来说无法支持。virtio也许能够通过定义一种通用的方式来让一个设备request page，并且暂停、恢复这个request的处理。virito队列本身就不是顺序处理的，也就是说哪怕某个request被阻塞住一直在等page fault处理完毕，也不影响这个设备的其他处理工作。

Future optimizations

此外，还是需要对virtio工作方式进行一些改进来让硬件实现得更快一些。在队列中等待处理的工作数量需要让设备能从memory中取到。如果我们从驱动中去除掉对这个信息的依赖，而让设备自己处理，那么就可以减少设备对memory的访问数量。

目前已经有一种名为“event index”的中断消除机制，会把相应的状态存在guest RAM里面。对guest RAM的访问都需要硬件设备来进行DMA传输，这种操作开销比较大，也会浪费PCI总线带宽，尤其是如果RAM里面内容根本没有改变过的情况下。这里还是需要一个对硬件实现方式更加友好的方案。类似地，我们经常使用中断合并方式来减少在中断频繁触发情况下的CPU开销。用硬件实现的话，也可以很容易的利用这个方式。

大家可以很容易地参与到virtio Technical Committee指定标准的过程中，任何人都可以。也非常欢迎硬件供应商参与进来一起改进硬件设计。

Conclusion

virtio规范起初完全是针对用软件来实现设备的，不过现在也开始有相应的硬件设备了。Tsirkin的演讲介绍了virtio 1.1对硬件设备支持有什么改善，同时也列出了不少工作需要继续进行，例如热迁移等。尽管硬件virtio设备还不是很常见，硬件供应商和云服务商认为这些虚拟设备变成硬件设备的一天已经不会太远了。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～