Page 46 - 《软件学报》2020年第10期
P. 46

3022                                  Journal of Software  软件学报 Vol.31, No.10, October 2020

         权模式(non-root mode)下执行一些特定的虚拟机相关操作而不会引发任何下陷到虚拟机监视器的行为.截至目
         前,VMFUNC 指令仅仅支持扩展页表指针(EPT pointer,简称 EPTP)切换这一功能,该功能允许客户端虚拟机在
         非特权模式下由一条 VMFUNC 指令执行 EPTP 的切换.为了防止切换到错误的内存区域,需要预先在虚拟机监
         视器中为对应客户虚拟机配置 EPTP 列表(EPTP list),应用程序只能从该列表中选择合法的 EPTP,而一个 EPTP
         列表中最多可以容纳 512 个 EPTP.
             VMFUNC 指令由于其无下陷的特点相较于传统方法有着很大的性能优势,在该指令出现之前,如果一个客
         户虚拟机试图完成更改 EPTP,需要由非特权模式切换到特权模式修改 VMCS 中 EPTP 域的值,然后再由特权模
         式返回到非特权模式,其中,仅仅非特权模式到特权模式的切换就需要花费不少于 300 个 cycle.相比之下,一条
         VMFUNC 指令可以完成与上述整个流程同样的功能,在开启了(virtual processor identifier,简称 VPID)功能的情
         况下只需要花费 134 个 cycle.VMFUNC 也因此被很多已有工作              [20,21] 所采用.

         2    现有工作分析
             根据上文所述背景,本文选择 API 转发的方法作为 Wormhole 的基础方法以兼顾性能和可用性.为了能够有
         针对性地解决现有基于 API 转发的虚拟化方案中存在的关键问题,本节调研了目前公开的相关工作并进行了
         深入的测试与分析.
         2.1   客户端与服务端交互模式的问题
             在 API 转发方法下,服务端进程与客户端进程的交互模式有多种选择.
             (1)  以 GVirtuS 为代表的方案选择了 Host-VM 模式,即将服务端进程放置在主机操作系统中,客户端进程放
         置在虚拟机或容器中.该模式下,加速器的管理与主机操作系统耦合,主机操作系统的内核需要分饰两角,不仅
         要扮演客户虚拟机的管理者角色,还要负责运行加速器的驱动程序.这样既打破了单一功能原则(single
         responsibility principle),又只能同时支持一个版本的加速器驱动,给整个系统的运维带来了困难.例如,当操作系
         统不支持动态地升级驱动程序时,可能需要重启使新版本驱动生效,但是正在运行着的客户虚拟机显然是无法
         避免受到影响的,在云服务提供商看来这是无法接受的.
             (2)  以 vCUDA [22] 为代表的方案选择了 VM-VM 模式,服务端进程与客户端进程分别放置在不同的客户虚
         拟机中,可以选择多种跨虚拟机的通信方式进行数据交换.传统的基于网络或共享内存的通信方式由于系统调
         度等因素造成了较大的性能损失,而近年来的一些工作                    [21] 已经提出了虚拟化环境下的快速通信方式,但是对于
         具有较复杂操作系统(如主流的 Linux 系统)的虚拟机却无能为力.此外,随着加速器种类以及配套软件的不断更
         新,这类方案也未能提出适合的配套进化措施.
             现有的 API 转发方案的主要问题表现在性能方面,而主要的性能损失来自于通信模块.从目前了解到的基
         于 API 转发的各类系统来看,通信方式主要分为以下几种.
             (1) TCP/IP 通信方式  [23] .由于需要经过多次的内存拷贝,带来了大量的额外开销:以主流的 Linux 操作系统
         利用套接字(socket)进行单向 TCP 传输为例,用户态进程在发送数据时需要先将待发送的数据拷贝到内核的缓
         冲区中,然后内核中的 TCP 栈会利用本地网卡将数据发送给目标地址.从上述流程可以看出,为了在两个进程间
         拷贝一段数据,TCP/IP 通信方式引入了两次额外内存拷贝,如果考虑 I/O 虚拟化,额外内存拷贝的次数可能会翻
         倍,以常见的 Virtio 方式   [24] 为例,一次单向 TCP 通信会增加两次虚拟机到主机内核缓冲区的内存拷贝.除此之外,
         在服务端进程等待客户端请求时,CPU 会陷入睡眠或调度,等到网卡收到数据后会发送中断唤醒 CPU,这些异步
         操作也会带来不小的延迟.
             (2)  共享内存(shared memory)方式.该通信方法通过在服务端进程和客户端进程之间建立一段共享的内存
         映射,消除了额外内存拷贝开销.然而,单纯的共享内存并未提供在数据拷贝完成后的通知机制,目前常见的通
         知机制是将能否共享一个信号量(semaphore)作为能否修改共享内存的标志.由于双方需要主动地轮询信号量,
         这样会导致 CPU 花费大量时间在没有实际作用的轮询和调度上,造成较高的延迟.
             (3)  远程直接内存访问(remote direct memory access,简称 RDMA)方式.RDMA 允许一台服务器直接访问另
   41   42   43   44   45   46   47   48   49   50   51