CN111459620A

CN111459620A - 安全容器操作系统到虚拟机监控器的信息调度方法

Info

Publication number: CN111459620A
Application number: CN202010270841.XA
Authority: CN
Inventors: 孙宇红; 孙宇霖
Original assignee: Individual
Current assignee: Individual
Priority date: 2020-04-08
Filing date: 2020-04-08
Publication date: 2020-07-28
Anticipated expiration: 2040-04-08
Also published as: CN111459620B

Abstract

安全容器操作系统到虚拟机监控器的信息调度方法。本发明提供了一种安全容器到虚拟机监控器的调度方法，包括虚拟机监视器和安全容器内核共享内存空间；构建两条安全容器内核与虚拟机监控器之间基于共享内存的消息队列；消息队列中放入安全容器内核的Hyper Call的内存指针；虚拟机监控器在共享内存中处理Hyper Call；处理后Hyper Call线程ID放入消息队列，由调度器获取处理后Hyper Call线程ID。本发明通过此队列的信息交换方式，当安全容器的虚拟CPU（vCPU）需要调用Hyper Call的时候，它不需要进行安全容器内核和虚拟机监控器之间的上下文切换，这样可以大大提高超级调用调用执行效率。

Description

安全容器操作系统到虚拟机监控器的信息调度方法

技术领域

本发明涉及计算机领域，涉及虚拟机，尤其是涉及基于消息队列的安全容器操作系统到虚拟机监控器的调度方法。

背景技术

Host OS是在物理主机上安装的操作系统，然后在这个Host OS操作系统上运行虚拟机监视器软件，这样就可以在物理主机上虚拟化出若干分区，可以分别安装不同的操作系统。对应的安装在虚拟分区上的操作系统叫做Guest OS。

虚拟机监视器（英语：virtual machine monitor，缩写为 VMM），VMM通过调用HostOS资源为Guest OS提供虚拟运行环境。VMM需要通过一个叫Hypervisor的系统软件与GuestOS通信。

虚拟机（KVM，Kernel-based Virtual Machine）是目前市场广泛采用的虚拟机软件，它的体系结构如下：1、KVM运行在Linux内核中；2、虚拟机运行在一个Linux操作系统进程中；3、虚拟机由应用和虚拟机操作系统组成。4、虚拟机操作系统与VMM的通信需要通过虚拟机通信或者共同分享虚拟化后的硬件资源（如内存）；这里的虚拟机操作系统既可以是一个完整的操作系统，例如windows或者Linux；也可以是轻量化的安全容器操作系统，例如Google的gVisor。

在这种基于虚拟机安全的容器运行环境中，虚拟机操作系统是一个轻量化的安全容器，这个安全容器运行在一个定制的容器虚拟机监视器中。安全容器操作系统与虚拟机监视器通信需要通过虚拟机提供的调度（KVM Hyper Call）。“KVM Hyper Call”的性能比较差，这是因为一次“KVM Hyper Call”需要两次上下文切换：a.安全容器到主机操作系统切换；b.主机操作系统到虚拟机监控器进程切换；这些上下切换的成本很高，在高吞吐率(Request Per Second，RPS) 的场景下，“KVM Hyper Call”成为了系统的瓶颈。

发明内容

本发明所要解决的技术问题是提供一种安全容器到虚拟机监控器的调度方法。

本发明解决上述技术问题所采用的技术方案为：安全容器到虚拟机监控器的调度方法，其特征在于包括：

虚拟机监视器和安全容器内核共享内存空间；构建两条安全容器内核与虚拟机监控器之间基于共享内存的消息队列；消息队列中放入Hyper Call的内存指针；虚拟机监控器在共享内存中处理Hyper Call；处理后Hyper Call线程ID放入消息队列，由调度器获取处理后Hyper Call线程ID。

进一步的，消息队列包括呼叫队列和返回队列，安全容器内核中将Hyper Call信息放入安全容器的内核线程栈，Hyper Call信息在线程栈上的内存指针放入呼叫队列。

进一步的，虚拟机监控器Hyper Call处理线程由呼叫队列中读取Hyper Call信息进行处理。

进一步的，安全容器内核虚拟CPU将当前内核线程状态改为等待状态，并且由调度器模块中获取下一个准备的Ready线程调度执行。

进一步的，虚拟机监控器从安全容器内核线程栈中取出Hyper Call，处理后将Hyper Call线程ID放入返回列队。

进一步的，调度器模块由返回列队取得完成Hyper Call的安全容器内核线程ID，将此线程的状态改为Ready，等待调度。

进一步的，呼叫队列和返回队列的数据结构和构建方式相同，使用的数据结构的代码如下：

Struct Queue {

Queue dataQueue;

SpinLock lock;

}

进一步的，呼叫队列的方向是从安全容器内核到虚拟机监控器，返回队列的方向是从虚拟机监控器到安全容器内核。

进一步的，安全容器内核与虚拟机监控器之间同步使用基于内存原子操作的自旋锁。

与现有技术相比，通过此队列的信息交换方式，当安全容器的虚拟CPU（vCPU）需要调用Hyper Call的时候，它不需要进行安全容器内核和虚拟机监控器之间的上下文切换，这样可以大大提高超级调用调用执行效率。

附图说明

图1为本发明调度的示意图一。

图2为本发明调度的示意图二。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的术语 “包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块，本文中所出现的模块的划分，仅仅是一种逻辑上的划分，实际应用中实现时可以有另外的划分方式。

本发明提供一个基于消息队列的安全容器操作系统到VMM的Hyper Call通信机制。它的基本原理如下：

基于内存的消息队列：VMM和安全容器操作系统内核使用基于共享内存的消息队列通信，以避免高成本上下文切换；

基于自旋锁Spinlock的线程同步：VMM线程与安全容器内核线程通过基于共享内存SpinLock进行线程同步（linux中的自旋锁spinlock），同样避免高成本上下文切换同步；

基于安全容器操作系统内核线程栈的信息交换：超级调用Hyper Call参数和返回值都分配在安全容器内核线程栈，避免额外的内存分配。消息队列仅传递Hyper Call相关信息的指针和线程ID。

图1所示，需要构建两条安全容器内核与虚拟机监控器之间的基于共享内存消息队列。

呼叫队列：方向是从安全容器内核到虚拟机监控器。当安全容器内核需要调用虚拟机监控器的服务时，安全容器内核需要将Hyper Call相关信息指针放入呼叫队列;

返回队列：方向是从虚拟机监控器到安全容器内核的。当Hyper Call相关处理在虚拟机监控器处理结束之后，相关安全容器内核线程ID被放入返回队列;

图2所示，具体的，

当安全容器内核需要进行Hyper Call的时候，它的相关流程如下：

1)安全容器内核虚拟CPU将 Hyper Call信息压到当前安全容器内核线程栈上，包括：Hyper Call类型ID、Hyper Call参数和安全容器内核线程ID；

2)将Hyper Call信息在线程栈上的内存指针放入呼叫列队Call Queue；

3)安全容器内核虚拟CPU将当前内核线程状态改为等待Waiting状态，并且由调度器模块中获取下一个准备的Ready线程调度执行；

4)VMM宿主机操作系统线程中VMM Hyper Call处理线程由呼叫列队Call Queue中读取Hyper Call信息进行处理。

5)处理完成后，将返回值放到Guest内核栈上；然后由Hyper Call信息取出安全容器内核线程ID并且放入返回列队Return Queue；

6)调度器模块由 Return Queue”取得完成Hyper Call的安全容器内核线程ID，将此线程的状态改为Ready，等待调度。

这里呼叫队列和返回队列的数据结构和构建方式均相同。它们使用的数据结构的示意代码如下：

Struct Queue {

Queue dataQueue;

SpinLock lock;

}

它们每个字段的定义如下：

1.dataQueue: 它是一个标准的先进先出队列，它的基础数据结构可以是数组或者链表；

2.lock: 这是一个基于内存原子操作标准的自旋锁。当需要读取和压入数据到队列的时候，需要首先获取这个锁来保证数据的一致性。由于它是自旋锁，所以它可以在现在线程间直接同步，而不需要依赖于操作系统的同步系统调用。

安全容器内核与虚拟机监控器之间同步使用基于内存原子操作的自旋锁。

通过此队列的信息交换方式，当安全容器的虚拟CPU（vCPU）需要调用Hyper Call的时候，它不需要进行安全容器内核和虚拟机监控器之间的上下文切换，这样可以大大提高超级调用调用执行效率。

通过实际基于开源软件Redis的测试结果，在做高频率超级调用的情况下，基于本发明的吞吐量是基于KVM 超级调用软件gVisor的吞吐量大的2~3倍。

它可以降低延迟：这个机制避免基于”KVM Hyper Call”的高成本上下文切换，可以降低Hyper Call的延迟。

高吞吐量：在多个安全容器操作系统内核线程的场景下，内核线程在等待HyperCall的返回结果时，它可以切换到其他线程执行，这个切换不涉及到内核到VMM的切换；

零堆内存分配：Hyper Call参数放到安全容器操作系统内核栈上，仅指向Hyper Call参数栈指针传递到VMM。不需要额外分配堆内存。

零内存复制：Hyper Call参数仅包括内存指针，由于VMM和安全容器操作系统内核共享部分内存地址空间，安全容器操作系统应用内存不需要复制到内核和VMM。

本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1.安全容器到虚拟机监控器的调度方法，其特征在于包括：

虚拟机监视器和安全容器内核共享内存空间；

构建两条安全容器内核与虚拟机监控器之间基于共享内存的消息队列；

消息队列中放入安全容器内核的Hyper Call的内存指针；

虚拟机监控器在共享内存中处理Hyper Call；

处理后Hyper Call线程ID放入消息队列，由调度器获取处理后Hyper Call线程ID。

2.根据权利要求1所述的安全容器到虚拟机监控器的调度方法，其特征在于，消息队列包括呼叫队列和返回队列，安全容器内核中将Hyper Call信息放入安全容器的内核线程栈，Hyper Call信息在线程栈上的内存指针放入呼叫队列。

3.根据权利要求1所述的安全容器到虚拟机监控器的调度方法，其特征在于，消息队列包括呼叫队列和返回队列，虚拟机监控器Hyper Call处理线程由呼叫队列中读取HyperCall信息进行处理。

4.根据权利要求1所述的安全容器到虚拟机监控器的调度方法，其特征在于，安全容器内核虚拟CPU将当前内核线程状态改为等待状态，并且由调度器模块中获取下一个准备的Ready线程调度执行。

5.根据权利要求1所述的安全容器到虚拟机监控器的调度方法，其特征在于，消息队列包括呼叫队列和返回队列，虚拟机监控器从安全容器内核线程栈中取出Hyper Call，处理后将Hyper Call线程ID放入返回列队。

6.根据权利要求1所述的安全容器到虚拟机监控器的调度方法，其特征在于，消息队列包括呼叫队列和返回队列，调度器模块由返回列队取得完成Hyper Call的安全容器内核线程ID，将此线程的状态改为Ready，等待调度。

7.根据权利要求1所述的安全容器到虚拟机监控器的调度方法，其特征在于，消息队列包括呼叫队列和返回队列，呼叫队列的方向是从安全容器内核到虚拟机监控器，返回队列的方向是从虚拟机监控器到安全容器内核。

8.根据权利要求1所述的安全容器到虚拟机监控器的调度方法，其特征在于，安全容器内核与虚拟机监控器之间同步使用基于内存原子操作的自旋锁。

9.根据权利要求1所述的安全容器到虚拟机监控器的调度方法，其特征在于，消息队列包括呼叫队列和返回队列，呼叫队列和返回队列的数据结构和构建方式相同，使用的数据结构的代码如下：

Struct Queue {

Queue dataQueue;

SpinLock lock;

}。