关于2.0 vmm 的思考和疑惑

发布于 2013-11-25 23:12:39
刚刚读了ffxz关于2.0的vmm的pdf,我自己也是做过多年嵌入式开发的,也做过一段时间的虚拟化。从文档上说,我感觉ffxz要实现的vmm 就是一个hypervisior,不管linux还是rt都运行在它上面并通过它访问硬件,这个vmm还负责os间的隔离和通讯。这当然有意义了,xen太大,kvm必须依赖于linux。但是实现这样的vmm还是有挑战的,首先是效率,ffxz文档上提出的是半虚拟化的架构,也就是依赖软件如bt技术来实现的,半虚拟化必然导致效率的下降,当然这样可以兼容更多的cpu架构。其次如何去实现虚拟的设备层来在os间共享或独占设备?最后必要性,如果已经能运行linux,rt还需要运行吗?ffxz的文档说,rt来保证实时性,但同时运行在半虚拟化vmm的rt实时性究竟怎么样呢?
如果要运行vmm,我猜cpu至少是cortex a系列的cpu,那么以前cortex m系列的cpu是否也要实现vmm呢?或者直接不对其进行支持。
建议如果cpu支持硬件虚拟化的话,还是上全虚拟化的架构较好,设计简单而且效率较高。
以上只是建议,欢迎拍砖。

查看更多

关注者
1
被浏览
6.2k
15 个回答
bernard
bernard 2013-11-26
没错,VMM就是一个hypervisor。不过在这个VMM上运行RT-Thread还是很有必要,即使是类似xen的,它在内部也有部分这种调度,甚至是小型的TCP/IP协议栈,更重要的是虚拟设备,例如Linux的Virtio。

RT-Thread/VMM实现成native方式,所以所有的代码、指令都需要原生的数据。例如硬件是一个AM335x的硬件,那么必须要Linux的AM335x版本才能够跑起来,RT-Thread也需要一份RT-Thread/AM335x的移植才能够跑起来。这样的好处在于双方的性能损失非常小,例如Linux的损失就在个位数百分比。

RT-Thread与Linux间的通信是通过VBUS来进行,这个在PPT中有部分介绍。运行在VMM模式下的RT-Thread实时性能和单独运行RT-Thread相差不大,目前的开销(相比原始的RT-Thread)主要是Linux在切换模式时有短暂的额外开销。这部分我们也在考虑是否能够优化掉。

运行RT-Thread/VMM只需要ARM926EJ-S这种级别的CPU就可以运行起来了,再往上的可以是各种Cortex-A 32位处理器。ARM Cortex-M不能够跑Linux,所以不能够支持这种方式。目前我们的实现局限于硬件,所以暂时还不能开启硬件虚拟化,后续我们会在Zynq上做更多的工作(支持TrustZone)
cini
cini 2013-11-26
从文档上看 vmm是独立于linux的,为什么2.0的vmm要求cpu能运行linux?vmm如何保证os间的隔离,尤其在arm上不使用硬件虚拟化的情况下,如何高效的trap 操作系统的特权指令?除了设备虚拟化外,内存mmu的虚拟化和中断的虚拟化rt vmm如何实现。可能问题太多,你们目前有无demo,是否已经open能供参考。trustzone据我所知很多a9的core都不支持,如beagleboard的omap3和exynos4412都不支持。znqy的a9不太确定。
cini
cini 2013-11-26
可以考虑a7的处理器如全志的a20,我在cubieboard上已经验证过其对虚拟化的支持。a7在软件架构上完全兼容a15的。
bernard
bernard 2013-11-27
A20的资料哪里有呢?
cini
cini 2013-11-27
网上有下的,不过它的编程手册比较简陋,虚拟化部分主要还是要参考arm的手册hekvm或者xen的代码。你留个邮箱我发给你。
bernard
bernard 2013-11-27
网上有下的,不过它的编程手册比较简陋,虚拟化部分主要还是要参考arm的手册hekvm或者xen的代码。你留个邮箱我发给你。


我的邮箱就在我的签名档中,谢谢。
ffddybz
ffddybz 2015-08-26
没错,VMM就是一个hypervisor。不过在这个VMM上运行RT-Thread还是很有必要,即使是类似xen的,它在内部也有部分这种调度,甚至是小型的TCP/IP协议栈,更重要的是虚拟设备,例如Linux的Virtio。

RT-Thread/VMM实现成native方式,所以所有的代码、指令都需要原生的数据。例如硬件是一个AM335x的硬件,那么必须要Linux的AM335x版本才能够跑起来,RT-Thread也需要一份RT-Thread/AM335x的移植才能够跑起来。这样的好处在于双方的性能损失非常小,例如Linux的损失就在个位数百分比。

RT-Thread与Linux间的通信是通过VBUS来进行,这个在PPT中有部分介绍。运行在VMM模式下的RT-Thread实时性能和单独运行RT-Thread相差不大,目前的开销(相比原始的RT-Thread)主要是Linux在切换模式时有短暂的额外开销。这部分我们也在考虑是否能够优化掉。

运行RT-Thread/VMM只需要ARM926EJ-S这种级别的CPU就可以运行起来了,再往上的可以是各种Cortex-A 32位处理器。ARM Cortex-M不能够跑Linux,所以不能够支持这种方式。目前我们的实现局限于硬件,所以暂时还不能开启硬件虚拟化,后续我们会在Zynq上做更多的工作(支持TrustZone)


Hi,根据 RTT 的各种资料简要了解了下单核的 RTT/Linux 执行技术,以下是我的疑问,可能不大正确或者理解不到位:
1、benard 说这是一种半虚拟化的技术,但是如果把 RTT 作为 hypervisor 的话,其仅仅实现了中断虚拟化,好处在于减少关中断时间,而 CPU 虚拟化和设备虚拟化并没有实现,所以
1)即使通过 ARM 的domain技术(并不是特别了解)实现了内存等等的隔离,那么如何实现计算资源上的隔离,如怎么限制每个系统的 CPU 利用率。
2)没有设备虚拟化的话,按照 benard 的说法是每个系统都要实现自己的设备驱动,比如说如果板子上只有一个网口的话,那么只有其中一个系统能够使用网络?这种分配策略是怎么样的?
2、RTT 的启动是依赖于 Linux 的,那么其启动时间能做出保证吗?或者是能不能将 VMM 组件独立于 Linux,启动 VMM 后再启动RTT 这样能够加快 RTT 的启动?
liandao
liandao 2015-09-01
没错,VMM就是一个hypervisor。不过在这个VMM上运行RT-Thread还是很有必要,即使是类似xen的,它在内部也有部分这种调度,甚至是小型的TCP/IP协议栈,更重要的是虚拟设备,例如Linux的Virtio。

RT-Thread/VMM实现成native方式,所以所有的代码、指令都需要原生的数据。例如硬件是一个AM335x的硬件,那么必须要Linux的AM335x版本才能够跑起来,RT-Thread也需要一份RT-Thread/AM335x的移植才能够跑起来。这样的好处在于双方的性能损失非常小,例如Linux的损失就在个位数百分比。

RT-Thread与Linux间的通信是通过VBUS来进行,这个在PPT中有部分介绍。运行在VMM模式下的RT-Thread实时性能和单独运行RT-Thread相差不大,目前的开销(相比原始的RT-Thread)主要是Linux在切换模式时有短暂的额外开销。这部分我们也在考虑是否能够优化掉。

运行RT-Thread/VMM只需要ARM926EJ-S这种级别的CPU就可以运行起来了,再往上的可以是各种Cortex-A 32位处理器。ARM Cortex-M不能够跑Linux,所以不能够支持这种方式。目前我们的实现局限于硬件,所以暂时还不能开启硬件虚拟化,后续我们会在Zynq上做更多的工作(支持TrustZone)


Hi,根据 RTT 的各种资料简要了解了下单核的 RTT/Linux 执行技术,以下是我的疑问,可能不大正确或者理解不到位:
1、benard 说这是一种半虚拟化的技术,但是如果把 RTT 作为 hypervisor 的话,其仅仅实现了中断虚拟化,好处在于减少关中断时间,而 CPU 虚拟化和设备虚拟化并没有实现,所以
1)即使通过 ARM 的domain技术(并不是特别了解)实现了内存等等的隔离,那么如何实现计算资源上的隔离,如怎么限制每个系统的 CPU 利用率。
2)没有设备虚拟化的话,按照 benard 的说法是每个系统都要实现自己的设备驱动,比如说如果板子上只有一个网口的话,那么只有其中一个系统能够使用网络?这种分配策略是怎么样的?
2、RTT 的启动是依赖于 Linux 的,那么其启动时间能做出保证吗?或者是能不能将 VMM 组件独立于 Linux,启动 VMM 后再启动RTT 这样能够加快 RTT 的启动?

说一点我理解:
1)domain仅仅保护了内存,没有对计算资源做隔离,比如限制CPU使用率之类。
2)没有设备虚拟化,最理想的应用应该RT-THREAD所需使用的设备和LINUX使用的设备不重,各自独立使用;如果要复用一个外设,那么就必须有虚拟化外设的考虑了
3)目前的方式,RT_THREAD不是完整的hypervisor,因此没法先启动RT-THREAD,然后再启动LINUX,若是这样,就设计到怎么引导LINUX启动的问题,估计难度比较到。

到目前为止,不知道有多少人在AM335x实际硬件上重现了VMM,期待有已经重现的人,来讲讲他是怎么做的--毕竟rtthread的代码中VMM无法直接应用于AM335x。
bernard
bernard 2015-09-01
在RT-Thread启动后再去做Linux启动,这个是可以的,但是这样要修改Linux内核。VMM总体来说,觉得还是对Linux内核修改过多了。
liandao
liandao 2015-09-01
在RT-Thread启动后再去做Linux启动,这个是可以的,但是这样要修改Linux内核。VMM总体来说,觉得还是对Linux内核修改过多了。

vmm对linux的改动,比起xenomai的i-pipe对内核的改动,那是很小的改动了,但即使vmm这500行对kernel的改动,若看懂它并把握它,需要不少的linux功底呀!也挺难的。
grissiom
grissiom 2015-09-16
在RT-Thread启动后再去做Linux启动,这个是可以的,但是这样要修改Linux内核。VMM总体来说,觉得还是对Linux内核修改过多了。

vmm对linux的改动,比起xenomai的i-pipe对内核的改动,那是很小的改动了,但即使vmm这500行对kernel的改动,若看懂它并把握它,需要不少的linux功底呀!也挺难的。


尤其是汇编部分,233
ljt8015
ljt8015 2015-09-26
是不是相当于 一个cpu同时运行两个os,两个os操作的设备不可重叠,两个os之间通过vbus进行通信。
liandao
liandao 2015-09-29
是不是相当于 一个cpu同时运行两个os,两个os操作的设备不可重叠,两个os之间通过vbus进行通信。

是的,假如没有设计对外设的复用,那么就剩下两个OS间数据交换--也就是vbus通讯.

撰写答案

请登录后再发布答案,点击登录

发布
问题

分享
好友