对于云计算用户来说，过长的KVM虚拟机创建及启动时间非常影响体验，特别是超大规格的KVM异构虚拟机。以350G内存为例，创建时间需要2分钟，当用户此时创建虚拟机是用于快速恢复业务时，2分钟的创建等待时间完全超出用户的可忍受值。另外，对于云计算的后台管控系统而言，过长的阻塞时间极大地影响了系统调度效率。

一直以来，阿里云异构计算团队在KVM性能优化方面都有大量的投入，积淀了大量实战经验。阿里云异构计算团队创新性地提出了一种显著优化带有透传（pass-through）设备的KVM虚拟机创建及启动时间的方法，虚拟机的启动时间不再随着分配内存的大小而显著增加，即使虚拟机被分配了几百G甚至更多的内存，用户感知的启动时间依然没有明显增加。

在这套技术优化方案下，对于350G内存的虚拟机，创建及启动时间可从原来的120秒以上降低到20秒以内，效率整整提升了6倍以上；对于T级内存的虚拟机，预计创建效率可以提升10倍以上。

作为KVM社区最为重要和权威的大会，KVM Forum 2020有3个议题是与KVM 虚拟机创建及启动速度的优化有关，分别来自阿里巴巴、英特尔和滴滴，可见KVM社区及云计算业界对此问题的重视程度。阿里云工程师李伟男和郭成在KVM Forum 2020上详细介绍了阿里云KVM虚拟机创建及启动时间优化的具体技术实现，本文根据其演讲整理而成。

1、发现问题：内存越大、启动越慢， DMA map执行是耗时大户

众所周知，PCI设备透传是KVM虚拟化应用中一个非常重要的场景，而VFIO是当前最为流行的PCI设备透传解决方案，为了能够在应用层提供高效的DMA访问，在启用VFIO设备之前，需要将分配给虚拟机的所有内存都锁定并进行IOMMU页表的创建。

这么做的原因在于，DMA访问可能覆盖整个虚拟机的内存空间，并且DMA访问的内存不能被换出（swap）。所以，如果能够在物理设备DMA访问之前得知将要访问的地址空间，就可以在运行中进行内存锁定（pin）及IOMMU页表的创建。但目前并没有一个简单、高效的方法能够完成这一操作。为了虚拟机及设备的高效运行，目前开源社区采取的办法是在虚拟机创建时将所有分配给它的内存进行锁定并创建IOMMU页表（DMA map）。

由于DMA map是一个相对比较耗时的操作，在虚拟机内存相对较小时，总体耗时是可以接受的。但随着虚拟化市场及技术的发展，越来越多的用户开始使用超大规格的虚拟机，内存资源已从4G增长到384G甚至更高，随之带来的DMA map时间消耗问题也日益突出。

图1:虚拟机的创建及启动时间与内存大小关系

如图1所示，以开源社区的KVM虚拟化组件及Ubuntu18.04虚拟机为例，在虚拟机内存达到350G以上时，整个KVM 系统的启动时间将超过2分钟，其中绝大部分时间都消耗在DMA map执行操作中。在这2分钟里，对于用户来说虚拟机是一个黑盒，用户能做的只有静静等待，甚至不确定虚拟机是否仍然在正常创建中，完全处于未知的状态。

2、设计思路：异步DMA map，完美解决虚拟机创建耗时问题

为了解决这一个问题，阿里云异构计算团队研究了现有的虚拟化技术和实际应用场景。虽然DMA map 本身不能省去，但我们发现在系统启动过程中DMA访问虽然是随机的、但并不会访问到全部，由此阿里云异构计算团队提出了一种异步DMA map（async DMA map）的方法，即在虚拟机创建过程中仅map有限的内存空间，剩余的大部分内存空间可以在虚拟机启动过程中于后台异步map完成，从而保证用户可以快速地获取访问虚拟机的权限。

这时，如何保证虚拟机在启动过程中不会有设备通过DMA访问到需要异步map的内存就成为了关键。这个过程中，我们用到了大家比较熟悉的Virtio-balloon，因为Virtio-balloon设计之初即被用来占用虚拟机内存使用，因此我们提出的解决方案不会涉及到大量、复杂的软件改动，即可完美解决虚拟机创建耗时的问题。

图2:async DMA map设计思路

Async DMA map 主要设计思路就是：虚拟机创建时，低于4G内存空间的DMA map 请求会被正常处理，其他内存空间的DMA map操作将会等待virtio_balloon前端驱动加载完成后根据实际情况进行处理。

具体的操作流程如下：

首先，确保virtio_balloon驱动先于VFIO设备驱动加载。这样virtio_balloon驱动会在配置空间中获取初始的balloon大小，然后再根据balloon大小进行实际的虚拟机内存的分配，被分配的内存将从可用内存中去除。在没有释放前，其他设备将无法申请到这部分被占用的内存，那就不会被DMA访问到，也就不需要在这之前进行map。

其次，完成balloon，获得可异步执行map内存空间。Balloon的过程是经过很多次inflate操作完成的。每次操作完成后，前端的virtio_balloon会通知后端完成的inflate balloon大小及其对应的PFN，位于宿主机上的后端驱动收到通知后，会将PFN从消息队列中解析出来，并转换为IOVA记录在ballooned页表中。待balloon完成后，后端驱动会得到一张完整的被virtio_balloon占用的内存页表，这部分的内存空间即是可以异步执行map的部分。没有在页表中的内存可能会被其他设备通过DMA 访问，因此需要即刻完成map 操作。

最后，在保证虚拟机系统可继续正常启动的情况下，async DMA map正式开始。通过向virtio_balloon前端驱动触发deflate操作，从而向虚拟机归还一定大小的内存，前端virtio_balloon驱动会将释放的内存地址同步给后端驱动，后端驱动接收到被释放的内存地址空间后，触发同步的DMA map，通过分步的deflate及map，慢慢完成全部内存的映射、锁定，从而使虚拟机恢复到完整内存资源可用状态。

3.具体实践：三个关键点优化，进一步优化启动时间

在具体的实践中，我们进行了balloon临近地址空间自动合并、增加单次balloon页面大小和预处理机制等三个关键点的优化，以进一步优化启动时间。具体优化如下：

1.Balloon 临近地址空间自动合并。通过合并多次balloon的临近内存地址空间，可以显著地减少触发DMA map 的次数。因为virtio_balloon会在系统启动初期被加载，此时的内存使用较少，virtio_balloon申请到的内存地址绝大部分是连续的，临近内存地址的可合并率非常高。

2.增加单次balloon 页面大小。内存资源已经不再是非常稀缺的资源，当前virtio_balloon前端驱动中基于小页（4KB）大小的内存申请机制已经不太适合当前大规格实例的业务场景。基于业界用户实际应用场景的分析，我们将virtio_balloon单次申请的内存大小从4KB提高到2MB，这一举措可减少约98%的前后端通信消耗，从而显著减少了不必要的CPU资源占用。

3.预处理机制。为了更快的完成异步 DMA map 操作，其实可以预先开始进行DMA map 操作，而不是等待deflate触发并收到virtio_balloon 前端驱动发出的通知才进行。在接收到前端发出的通知后，只需要做释放地址已映射命中检测即可。如地址未命中则可以插入 DMA map操作，若命中则可以更快地返回通知给虚拟机进行后续的deflate操作。

图3：VM启动时间与内存关系（左）、QEMu初始化时间与内存关系（右）

如图3，经过上述的优化（初始保留8G内存给虚拟机），我们看到随着分配给虚拟机的内存增加，KVM虚拟机的启动时间及QEMU初始化时间均没有明显增加。即我们将350G内存KVM虚拟机的创建及启动时间从原来的120秒以上减少到20秒以下，QEMU初始化时间缩减到7秒以内。对于T级内存的用户，预计效率可提升10倍以上，可以极快地获得虚拟机的访问控制权限。

结语

未来，我们将持续依托阿里云智能，致力于云计算产品的性能及用户体验的优化，为用户提供便捷、高效的弹性计算产品。

创作场景

T 级内存，创建效率提升 10 倍以上，阿里云 KVM 异构虚拟机启动时间优化实践