CN110851239B - 一种type-i型硬实时高可靠性全虚拟化方法 - Google Patents

Abstract

本发明公开了一种TYPE‑I型硬实时高可靠性全虚拟化方法，在虚机管理器级别上通过模拟硬件得方式虚拟出虚拟机，所述的虚拟机主要包含处理器，内存，中断和外设，guest OS运行在所述的虚拟机上，所述的Guest OS有对应的hyperkernel上下文，Guest OS通过hypercalls的方式访问hyperkernel，Managers是虚机管理器里面的另外一部分上下文，以特权级别的方式运行在虚机管理器的内存空间中，完全靠事件来驱动，采用轻量级的发送/接收/回复消息机制同其它上下文交互，且为guests提供服务。本发明既能满足多个客户机操作系统正常运行，还能满足实时性确定性要求。

Description

一种TYPE-I型硬实时高可靠性全虚拟化方法

技术领域

本发明涉及虚拟化技术领域，具体涉及一种硬实时高可靠性虚拟化方法。

背景技术

随着多核技术的快速发展，处理器性能的逐步增强，多核虚拟化技术越来越成为获得最高的性能，以及实现最佳的隔离性的首先方案。在SMP(同构核)环境时，多核系统的特征通常表现为一种优势，因为所有的内核都由同一个操作系统来管理。但是，当你要在多核系统中同时运行两种以上的操作系统时，例如同时运行一套RTOS(嵌入式实时操作系统)和一套通用操作系统时，通过虚拟化技术来管理调度多个操作系统成为彻底，灵活，具有可扩展性的多核软件架构。

目前已有基于TypeI型的XEN解决方案以及基于TypeII型的KVM解决方案。这两种方案满足在一套硬件设备上同时运行多个客户机操作系统，但无法保证客户机操作系统实时性确定性的特殊要求。亟需一种既能满足多个客户机操作系统正常运行，还能满足实时性确定性要求的TypeI虚拟化方法。

发明内容

本发明的目的是为了克服已有技术的缺陷，为了解决虚拟机运行客户机操作系统实时性确定性要求的问题，提供一种TYPE-I型硬实时高可靠性全虚拟化方法。

本发明采用的技术方案为：

一种TYPE-I型硬实时高可靠性全虚拟化方法，在虚机管理器级别上通过模拟硬件得方式虚拟出虚拟机，所述的虚拟机主要包含处理器，内存，中断和外设，guestOS运行在所述的虚拟机上，所述的GuestOS有对应的hyperkernel上下文，GuestOS通过hypercalls的方式访问hyperkernel，Managers是虚机管理器里面的另外一部分上下文，以特权级别的方式运行在虚机管理器的内存空间中，完全靠事件来驱动，采用轻量级的发送/接收/回复消息机制同其它上下文交互，且为guests提供服务。

具体地，所述虚拟机中处理器虚拟化的要求：GuestOS的内核运行在Level1模式下，GuestOS的用户程序运行在Level0模式下，虚机管理器运行在Level2模式下；GuestOS的敏感指令在Level1模式和Level2模式下正常运行，虚机管理器模拟指令执行并返回结果。

具体地，所述虚拟机中内存虚拟化的要求：允许用户准备两张MMU表，一张是GuestOS的，叫Stage-1表，一张是Hypervisor为GuestOS准备的，叫Stage-2表，虚拟化中将采用大物理地址扩展，Hypervisor启动时，会根据用户的内存配置大小给对应的GuestOS准备一张Stage-2表，GuestOS要访问一个内存需要经过Stage-1和Stage-2两张表的映射解析，如果任何一张表中找不到对应的地址，都会报异常供用户处理，同时在GuestOS进行切换的时候，Hypervisor除了恢复CPU上下文外，还需要把对应的Stage-1和Stage-2的基址地址恢复到相对的内存表基址寄存器中。

具体地，所述虚拟机中的同步机制的步骤是：

步骤1，CPU1上的Guest1通过hypercall的方式发生reset命令；

步骤2，Guest1的hyperkernel上下文发送消息给CPU2的CoreManager,并阻塞等待CPU2CoreManager的replay；

步骤3，CPU2CoreManager设置Guest2Hyperkernel控制结构中reset标志位；

步骤4，CPU2CoreManager返回响应的状态；

步骤5，Guest1Hyperkernel收到状态信息；

步骤6，Guest1hypercall返回状态并进行正常操作；

步骤7，等CPU2CoreManager完成发送工作后，Guest2的上下文可以在CPU2开始调度；

步骤8，Guest2hyperkernel检测到reset标志后开始reset这个guest。

附图说明

图1是本发明虚拟化方法中模块的结构图；

图2是本发明中Xen对外设IO的实现流程图；

图3是本发明中KVM对外设IO的实现流程图；

图4是本发明中虚机管理器对外设IO的实现流程图；

图5是本发明中Xen对中断的实现流程图；

图6是本发明中KVM对中断的实现流程图；

图7是本发明中虚机管理器对中断的实现流程图。

具体实施方式

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

如图1所示，虚拟化技术主要是虚机管理器级别上通过模拟硬件得方式虚拟出虚拟板卡或者虚拟机，guestOS就运行在该虚拟机上，虚拟机主要包含处理器，内存，中断，外设。

Hyperkernel提供内存以及上下文管理、调度机制、中断管理、Hypercall接口、内部消息通信机制IPC等。

VirtualBoard上下文提供创建虚拟板卡内存上下文、设备以及共享内存分配、上下文管理、调试等。

每个GuestOS都有一套对应的hyperkernel上下文：该上下文类似于虚机管理器的一个任务或者线程；GuestOS可以通过hypercalls的方式访问hyperkernel

Managers是虚机管理器里面的另外一部分上下文：他们以特权级别的方式运行在虚机管理器的内存空间中；完全靠事件来驱动；为guests提供各种服务(例如命令行，调度周期，外设管理)；采用轻量级的发送/接收/回复消息机制同其它上下文交互。

处理器CPU虚拟化

虚机管理器运用了硬件的虚拟化特性，让GuestOS和虚机管理器运行在不同特权的CPU模式下。保证了各自的隔离性，提高了安全性。

GuestOS的内核运行在Level1模式下；GuestOS的用户程序运行在Level0模式下；虚机管理器运行在Level2模式下

GuestOS的大部分敏感指令可以在Level1模式下正常运行。只有部分敏感指令需要经过内陷到Level2模式下，然后虚机管理器模拟该指令执行并返回结果。此过程对于GuestOS是透明的，GuestOS是不会感知到的。比如公共协处理的操作等等。

内存方面，硬件允许用户准备两张MMU表。一张是GuestOS自己的，叫Stage-1表。一张是Hypervisor为GuestOS准备的，叫Stage-2表。虚拟化中将采用大物理地址扩展。

Hypervisor启动时，会根据用户的内存配置大小给对应的GuestOS准备一张Stage-2表。GuestOS要访问一个内存需要经过Stage-1和Stage-2两张表的映射解析。如果任何一张表中找不到对应的地址，都会报异常供用户处理。同时在GuestOS进行切换的时候，Hypervisor除了恢复CPU上下文外，还需要把对应的Stage-1&Stage-2的基址地址恢复到相对的内存表基址寄存器中。

外设I/O虚拟化

在虚拟机上运行现有软件以及操作系统，虚拟机需要能过模拟特定的外设供这些软件或者操作系统来使用。因而如何以最小的系统开销来模拟这些外设IO成为虚拟机性能的关键点。

下面对比了XEN/KVM/虚机管理器三种方式的外设IO实现方式：

Xen的实现流程，如图2所示，展示了DomU模拟外设IO事件发生的整个生命周期图。从(1)点外设IO触发事件开始。在(2),(3)点通过XEN事件通道传送该IO事件到Dom0内核。随后在(4)点通过Dom0用户空间的QEMU来模拟外设IO事件。最后唤醒DomU并把控制权移交给DomU。

通过图2可以看出有如下几处额外开：Xen事件通道间的通信开销；Dom0内核与用户空间QEMU之间的上下文切换开销。

KVM的实现流程如图3所示，如图3所示，展示了KVM如何处理模拟外设IO事件的整个生命周期图。从(1)点外设IO触发事件开始，通过VM退出切换Guest模式到Host模式。在(2),(3)点通过Host领域的用户空间QEMU来模拟外设IO事件。最后在(4)点通过VM进入从Host模式切换回Guest模式。

VM进入以及退出过程中带来的上下文切换是造成KVM超重负载最重要的因素。

虚机管理器的实现流程如图4所示。

不像前面KVM/XEN的实现方式，虚机管理器在处理IO事件的过程中并没有带来额外的调度以及上下文切换开销。我们这里提供两种方式直通和模拟。

直通方式：在(1)点外设IO触发事件，虚机管理器根据外设分配配置信息找到该IO出发事件所需要激活的Guest。从(2)点切换到相对应的Guest，并执行Guest自带的IO驱动代码。好处就是能够充分利用Guest自带的丰富外设IO驱动代码。性能能同裸跑Guest相匹配。

模拟方式：在(1)点外设IO触发事件开始，在(2)点虚机管理器通过无休眠的方式模拟外设IO。模拟外设IO处理完毕后切换到相对应的Guest继续执行。需要虚机管理器单独实现外设IO的驱动部分，无休眠模拟外设IO能够确保固定的可预知的系统开销。

结论：通过以上对比，可以看出虚机管理器的实现方式额外开销小，适用于强实时性，高可靠性要求比较高的应用场景。

在虚拟化环境中，外部中断处理有着严格的时间限制。Hypervisor在处理外部中断过程中的额外开销会影响到外设IO的性能。根据目前硬件虚拟化的发展特性，Hypervisor和GuestOS采用了两套独立的中断向量表。这样Hypervisor和GuestOS可以根据自己的要求实现中断异常的处理。在模式切换过程当中，也可以避免中断向量表的软切换从而节省切换时间。

Hypervisor根据自己的调度策略调度多个GuestOS的运行。在GuestOS的切入切出过程当中Hypervisor需要保存以及恢复相关的CPU上下文。例如各个寄存器状态，堆栈指针，CPU工作模式等等。用软件维护实现一个虚拟的CPU。

Hypervisor是可确定的，具有最小的中断延时抖动。中断处理负载是不同的，取决于一下几个因素：

1.Guest是否是当前正在执行的。

2.Guest是否具有最高优先级。

3.Native自身的中断处理函数延时。

Xen的实现流程如图5所示，XEN中Dom0Linux内核包含了所有的外设驱动。因而所有的外设中断都需要通过Dom0。如图5所示，从(1)点外设中断产生开始，在(2)点路由该中断到Dom0。所有外设中断有Dom0在(3),(4)点处理完毕。如果外设中断到来的时候DomU正在运行中，只有等到Dom0处理中断完毕了，DomU才会被重新调度进来。可以外设中断处理会带来额外的调度开销。

KVM的实现流程如图6所示，图6显示了当Guest运行时KVM的中断处理流程。在(1)点外设中断会触发一次VM退出操作。Host内核在(2),(3)处理外设中断。中断处理完毕后在(4)点通过VM进入的方式重新唤醒Guest执行。在处理外设中断过程中的VM退出进入带来了严重的系统开销。不仅如此，如果该中断需要路由给当前KVMGuest的情况下，也会带来额外的调度开销。

虚机管理器的实现流程如图7所示，

虚机管理器能够直接处理外设中断。无需额外调度以及上下文切换操作。只有当该外设中断路由的Guest并不是当前正在运行Guest的情况下，需要通过一次额外的调度调度Guest来运行处理后续中断。

结论：虚机管理器较XEN/KVM在外设中断处理过程中使用了较少的任务调度以及上下文切换。大大减少了额外的系统开销，提升了外设中断响应时间的同时，也提高了外设IO的处理性能。

SMP同步机制：

一般多核SMP版本的操作系统以及大部分的虚机管理器都采用spinlocks的方式来包含临界区代码。该临界区代码可能会被多个CPU访问操作。我们的虚机管理器不采用spinlocks以及不确定性的原子操作。原子操作一般通过条件加载存储以及比较互换的汇编原来完成。之所以不采用spinlock或者原子操作的原因如下：

1.Spinlock或者原子操作的时间行为是不可确定的。

2.Spinlock或者原子操作一般借助忙等待的方式来实现，保证了其执行的线性性但却验证了影响了性能。

本发明的虚机管理器采用1.与CPU亲和力绑定的上下文或者线程。该上下文或者线程采用中断锁的方式。2.单个CPU读，单个CPU写，消息队列而无需核间锁机制。

这样确保了虚机管理器不会给RTOSguest引入新的不确定性。

(1)CPU1上的Guest1通过hypercall的方式发生reset命令；

(2)Guest1的hyperkernel上下文发送消息给CPU2的CoreManager,并阻塞等待CPU2CoreManager的replay；

(3)CPU2CoreManager设置Guest2Hyperkernel控制结构中reset标志位；

(4)CPU2CoreManager返回响应的状态；

(5)Guest1Hyperkernel收到状态信息；

(6)Guest1hypercall返回状态并进行正常操作；

(7)等CPU2CoreManager完成发送工作后，Guest2的上下文可以在CPU2开始调度了；

(8)Guest2hyperkernel检测到reset标志后开始reset这个guest。

优先级调度：

所有的guests和managers都有固定的优先级。采取简单的优先级调度，不支持优先级继承，不采用完全公平调度算法。

Managers运行在最高优先级上。由异常，中断以及hypercall这些事件来驱动，运行频率较低并且每次运行时间不会太长。

修改最高优先级guests的代码，让其在idle循环的代码中调用hypercall来显示告知虚机管理器调度出当前guests。调度机制是可抢占的。如果IRQ管理器检测到一个最高优先级的guest中断，虚机管理器会抢占当前guest。最高优先级guest中的最低优先级任务比所有其他guest中的任务优先级都要高。中断延时对于最低优先级guests是不可确定，有可能会非常长。但对于最高优先级guests可以满足其实时性要求。

时间片调度：

Guests以及部分managers被提前赋予固定的时间片。那些没有时间片的managers可以抢占guests执行。

没有优先级的概念，完全采用轮转调度。如果有一个conext无事可做时，同样要等到它所在的时间片耗尽为止。这样会造成一定程度的资源浪费。所有的调度都是在系统时钟的驱动下统一进行的。这样保证了调度机制的可确定性。

确保多个guests都能得到准确的执行时间。中断延时对于所有的guests来说是比较差的，但是最大延时时间是确定的。

调度处理时间会存成一定程度的浪费：Guests依然会被调度即使他们的任务是idle状态。Managers只有运行调度了才可以执行，也存在调度了但没有任务可做的情况。

虚机管理器有效的优化了中断上下文切换的系统开销。通过直通和模拟的方式减少了外设IO驱动处理过程中的切换次数，都能有效提高虚拟机过程中外设IO处理效率的问题。直通方式在有效利用guest丰富的现有驱动的同时也大幅度缩短了从硬件中断产生到guest感知中断并处理的时间。模拟方式虽然给虚机管理器引入了需要填写新的外设驱动的额外工作，但也从根本上解决了外设IO高效处理的系统要求，简化了guest的后期外设IO处理工作。同时虚机管理器通过自身提供的优先级调度方式，并结合外设配置接口设定硬实时性要求guest为最高优先级通用性guest为低优先级，可以满足硬实时性操作系统与通用操作系统的完美融合。虚机管理器同时也提供了时间片调度方式，可以满足各个guest执行时间确定已经中断执行时间完全可控的确定性要求。

Claims (3)

1.一种TYPE-I型硬实时高可靠性全虚拟化方法，其特征在于，在虚机管理器级别上通过模拟硬件的方式虚拟出虚拟机，所述的虚拟机包含处理器，内存，中断和外设，Guest OS运行在所述的虚拟机上，所述的Guest OS有对应的hyperkernel上下文，Guest OS通过hypercalls的方式访问hyperkernel，Managers是虚机管理器里面的另外一部分上下文，以特权级别的方式运行在虚机管理器的内存空间中，完全靠事件来驱动，采用轻量级的发送/接收/回复消息机制同其它上下文交互，且为guests提供服务；

所述的虚机管理器采用：与CPU亲和力绑定的上下文或者线程，该上下文或者线程采用中断锁的方式；单个CPU读，单个CPU写，消息队列无需核间锁机制；这样确保了虚机管理器不会给RTOS guest引入新的不确定性；

所述虚拟机中的同步机制的步骤是：

步骤1，CPU1上的Guest1通过hypercall的方式发生reset命令；

步骤2，Guest1的hyperkernel上下文发送消息给CPU2的Core Manager,并阻塞等待CPU2 Core Manager的replay；

步骤3，CPU2 Core Manager设置Guest2 Hyperkernel控制结构中reset标志位；

步骤4，CPU2 Core Manager返回响应的状态；

步骤5，Guest1 Hyperkernel收到状态信息；

步骤6，Guest1 hypercall返回状态并进行正常操作；

步骤7，等CPU2 Core Manager完成发送工作后，Guest2的上下文可以在CPU2开始调度；

步骤8，Guest2 hyperkernel检测到reset标志后开始reset Guest2。

2.根据权利要求1所述的高可靠性全虚拟化方法，其特征在于，所述虚拟机中处理器虚拟化的要求：Guest OS的内核运行在Level1模式下，Guest OS的用户程序运行在Level0模式下，虚机管理器运行在Level2模式下；Guest OS的敏感指令在Level1模式和Level2模式下正常运行，虚机管理器模拟指令执行并返回结果。

3.根据权利要求1所述的高可靠性全虚拟化方法，其特征在于，所述虚拟机中内存虚拟化的要求：允许用户准备两张MMU表，一张是Guest OS的，叫Stage-1表，一张是Hypervisor为Guest OS准备的，叫Stage-2表，虚拟化中将采用大物理地址扩展，Hypervisor启动时，会根据用户的内存配置大小给对应的Guest OS准备一张Stage-2表，Guest OS要访问一个内存需要经过Stage-1和Stage-2两张表的映射解析，如果任何一张表中找不到对应的地址，都会报异常供用户处理，同时在Guest OS进行切换的时候，Hypervisor除了恢复CPU上下文外，还需要把对应的Stage-1和Stage-2的基址地址恢复到相对的内存表基址寄存器中。

Images