Toggle navigation
首页
问答
文章
积分商城
专家
专区
更多专区...
文档中心
返回主站
搜索
提问
会员
中心
登录
注册
RT-Thread一般讨论
[转一些文章] VMM vs Microkernel
发布于 2010-02-05 09:53:02 浏览:4805
订阅该版
>> 按,这些基本上属于OS的前沿地带,多多关注这些才知道当前的技术进展情况 (HotOS'05 Note)Are Virtual Machine Monitors Microkernels Done Right? Are Virtual Machine Monitors Microkernels Done Right? Steven Hand, Andrew War eld, Keir Fraser, Evangelos Kotsovinos, and Dan Magenheimery HotOS'05 (Note by Brady) 看到作者列表中熟悉的名字,就知道这是来自"The Xen guys"的声音。Xen的大获成功毫无疑问大大提高了他们的影响力,更多的人愿意聆听他们对OS的理解;当然,也有少数人不愿意听到这样的理解(如Heiser)。 2000 年,Rob Pike发表"Systems Software Research is Irrelevant",痛斥System研究者不思进取,所做的研究在学术界外毫无影响力,再无80-90年代初那种轰轰烈烈的创新。3年以后,Xen 横空出世,2年的飞速发展及在工业界的巨大影响力,让Hand等人有了底气。 本文对VMM和Microkernel的一些异同点进行了对比,提出:"We argue that modern VMMs present a practical platform which allows the development and deployment of innovative systems research: in essence, VMMs are microkernels done right." 首先,文章从历史的角度指出两者有很多共性,特别是在目标上;很多时候两者的界限非常模糊,比如denali是VMM,但uDenali可以属于Microkernel;L4开始时Microkernel,但后来发展成可以运行多个不同的OS。 两者不同的地方有以下三点: 1. Avoid Liability Inversion: Microkernel itself depends on application level components, such as pagers, to make forward progress. Various inelegant timeout and fallback mechanisms were required to avoid deadlock. 2. Make IPC Performance Irrelevant: First, since VMMs hold isolation to be a key goal, IPC between virtual machines is considerably less common in general. Secondly, we have determined that a clear separation between control and data path operations allows us to optimize for the common case. 3. Treat OS as Component: Guest OS need few/none changes. Compatibility. Microkernel有很多优点,而VMM也可以实现: 1. Narrow interfaces between system components providing easy extensibility of device and OS functionality. Indeed, it seems very likely that the exploration of how services and management will be structured in a multi-OS VMM system will continue to present many exciting research opportunities. 2. A small code base that can guarantee security more easily than monolithic kernels. Several groups have expressed interest in developing these ideas for Xen, using concepts from projects such as the Flask-derived SELinux. 3. Strong isolation providing opportunities for improved manageability. recently by VMMs has been to explore less performance-centric aspects of systems development. (e.g. migration, log&replay) 最后总结:Microkernel的许多优点,VMM也都能实现;而VMM能够运行商业OS的特性,对现有应用提供更好的兼容性使得其走出学院,更多地在工业界发挥影响力,这是Microkernel所不具备的。 马上,就会有一篇激烈的文章来反驳Hand,作者就是L4的开发人员,来自澳大利亚的Heiser。
查看更多
2
个回答
默认排序
按发布时间排序
bernard
2010-02-05
这家伙很懒,什么也没写!
>> from [http://hi.baidu.com/l4os/blog/item/a4f66600d3af0681e850cd57.html](http://hi.baidu.com/l4os/blog/item/a4f6 ... 0cd57.html) 这是来自HP的关于Xen和L4之间关系评价的一篇Paper,最早看到这篇Paper的一些Note,是来自Peking University的Andy Yang,觉得意犹未尽,找原文来看。(这是第一篇,描述VMM > Microkernel)。 虽然在这篇Paper里面,作者声称是Microkernel和VMM的比较,但是现在说Microkernel,几乎就等同于L4,因为现在唯一保持活力还在不断前进的Microkernel似乎也只有L4了。同样的,VMM的代名词就是Xen,而且,作者也是来自Xen小组,所以我是从一种Xen VS L4的角度来看待这篇Paper的。 研究动机:首先,Microkernel是一种OS,而且最初的Mach是基于裁减UNIX的角度来出发的,而裁减的最后发现只有IPC是不能裁减掉的,所以在 Paper中有了Communication Oriented的提法,而Microkernel的研究者们对于IPC Performance的研究投入了极大的精力,当然也出了很多的Paper。所以似乎Microkernel是从软件到硬件的设计过程。而VMM的初衷是需要运行多个OS,因此它提供了一个Layer,可以把硬件资源进行严格的分离,而多个OS之间如何通讯他们不做考虑。 至于Paper中所提高的Performance问题,不是VMM和Microkernel的关键区别,因为Xen自称可以可以为Guest OS提供极小的Performance Loss,但是同样OKL4则声称自己的OKL4Linux ARM与Native Linux的性能差距小于1%。因此,出发点是不同的。Microkernel仍然是在设计OS,而VMM抛开OS,目的是作一个Hardware Multiplexer。 系统架构: Avoid Liability Inversion 从架构图上看,VMM和Microkernel几乎没有区别,上面有多个Guest OS,下面是一个Layer,VMM = Microkernel。作者用了一个liability inversion来说明Microkernel的问题,作者认为Microkernel的一个主要特点是Microkernel依赖于用户空间的其他程序,并用Paper来作说明。我感觉作者的意思是说,因为在Microkernel中,每一个Component都以Server的形式出现,而且各个 Server都放在不同的地址空间。那么相当于把本来在一个Address Space可能出现的问题放到了其他的多个空间。比如:L4中的Pager是可以嵌套的,可以从下到上,形成一个彼此依赖的Pager树,所以一旦一个 Pager出了问题,那么所有的Pager,包括依赖Pager的所有程序都会出问题。而在Xen中,没有Pager的感念,Xen的内存管理器只是用来分隔内存,用来规定Dom1用多少,Dom2用多少,至于Dom1和Dom2内部的内存管理,那是Dom内部的事情,不用Xen来管理。 个人以为:C/S架构从来都不是Microkernel OS的特点,C/S架构应该是SawMill Linux的特点,在SawMill Linux中,Jochen提出了这种Layered Resource Management的观点,DROPS是SawMill Linux的一个比较典型的例子。但是也有不采用C/S的L4-Based OS,Mungi 和Iguana(From Australia)就没有采用这种C/S方式。 Make IPC Performance Irrelevant 关于IPC,就像前面所提到的,IPC在Microkernel design中占据了一个非常重要的位置,而且也出了很多的Paper。在VMM design中,IPC design不在是一个关键的问题(不关键,不代表没有,在Xen中,依然需要IPC,主要是为了满足Device Driver Multiplex)。作者列举了这么些理由:1)isolation是Xen的主要目标,domain communication不是一个关键问题。VMM设计目标是把每一个OS都当作一个Schedule和Protect的对象,因此Fast Protected Synchronous IPC对于Xen来说,是不需要的。可以理解,Xen的主要目标是提供Server Virtulization技术,如果有一个PPC的机器,在上面跑了10几个Linux,每个Linux都用来作Apache Server的话,那么彼此之间根本不需要通信。2)但是,有些情况下,Communication是必须的,就像前面说的Device Driver的问题。如果仅仅是使用普通的Asynchronous IPC来进行Device Driver的消息传递,那么显然性能上达不到要求,这个问题VMM是通过Optimization来完成的,具体如下:Data和Control消息分开传递,Control消息使用Synchronous IPC,Data使用Asychronous Producer-Consuer Ring来完成。这样,可以充分利用系统资源而且达到较好的性能(Synchronous可以有保证的响应时间,但是比使得系统很 Busy;Asychronous的响应时间不能保证,但是相对而言,可以不使系统那么Busy)。 Microkernel Design采用了一个比较ideal的设计,以IPC (RPC)为核心,然后构造OS,所以整个系统就是由一堆保护的很好的Component组成的一个集合(这个描述太精确了,赞一个)。而VMM Design采用了一个比较Pragmatic的设计,不考虑系统的coherency,只是把整个系统划分成几块,而每个快(Guest OS)内部如何处理,是Guest OS的事情,与VMM无关。而Guest OS之间的通讯,就相当于一个Guest OS在使用一个Device Driver,control和data消息分别通过asynchornous(文章前面说,control是synchronous,后面又说 asychronous)和Asychromous producer-consumer ring buffer进行传递。 个人观点:作者的评价很中肯,Microkernel是一个Academic Design,似乎在某些时候准求系统的purity;而VMM则是一个pragmatic design,一切为了实用。 Treat the OS as a Component 关于Microkernel和VMM的区别,一个明显的不同之处是在于对于OS Componentization的粒度不同。首先,在Microkernel之上构建一个OS,难度显然大于在在VMM之上运行一个OS。这点没有意见,无论是L4Linux还是OKL4Linux,其在Linux内核中所增加的代码都远远超过Xen Linux的代码(我目前在Port Partikle到Fiasco,感觉就像是Port了一个small Linux),L4Linux其实就相当于重新作了一个Linux到L4 CPU的移植,需要模拟所有底层ARCH相关部分的接口。其次,Xen是依赖于Dom0的,所以所有Xen的开发都是基于Dom0的开发,很多用户都比较熟悉Domain0 Linux或者Domain0 Windows。而L4,则比较困难,如果基于L4编程,则用户需要熟悉L4 Manual,对于工业化推广,这的确是个弱点。关于已有的工具的使用,作者列举了一个Storage的例子,说是因为这个Storage提供了 Linux Similar的Block Layer,所以很容易使用。这点其实在L4已经有一定程度的解决,Fiasco小组的解决方案DDE (Device Driver Environment)可以重用所有的Linux Device Driver和BSD Device Driver,而Pistachio小组的解决方案则是把整个Linux当作一个Device Driver Server,同时提供跟Linux相同的接口(这里),他们的解决方案叫DDOS(Device Driver OS)。 The future for VMMs 作者也认为VMM的开发者从Microkernel Community Research里面吸收了思想,比如narrow interface和small code base等,以及关于Microkernel Community在trusted computing和security computing等领域的研究成果,而且有好多小组正在开展trusted computing based on Xen云云。此外,作者认为VMM design优于Microkernel design的一个方面(或者叫innovative feature)在于VMM抛弃了performance-centric的思想。其实,不尽然,VMM之所以在Server上面取得如此大的成功有二:1)Simple 2)Performance。Performance是取得工业界认可的一个重要因素,至于Simple,刚开始的时候,所有的系统都是很Simple 的,比如Linux 0.1,但是到了Linux-2.6,我想没有人会鼓吹it is a simple system。 Conclusion: Paper的的title以及2者评价都polite,他们首先驳斥了关于Academic OS Research的一个outragenous的观点,后来又驳斥了Academic OS is negeligble的2个观点。可能是因为Xen其实也是从Cambrige出来的,所以应该也是一种Academic OS,不过很快被工业界所接受。然后指出,Xen其实一个Microkernel Done Right,隐含的就是L4就是Microkernel Done Wrong。所以,他们认为:VMM Design应该是一种更好Microkernel Design。从这个起点来看,作者仍然认为VMM is a Microkernel.其实,Xen小组以前就开发过几个Microkernel。 个人观点:L4从80年代末开发,90年代鼎盛,21世纪的头10年才慢慢进入市场(OKL4,PikeOS),而Xen前后开发不过几年时间,很快就进入了市场,成为Open Source Star, 不能说这是一个偶然现象。个人以为其中应该有一些商业原因在里面,比如L4在德国发展了将近20年,但是最后投入商用的是在Australia。这是个问题不是从技术角度可以解释的。 关于技术问题,比如Synchronous和Asychronous的争论,我觉得作者说的有一定的道理。但是如果全部采用Asychronous和不关心IPC的问题。对于Server Virtualization没有问题,因为Server都是使用基于Network提供服务的,只要提供足够好的Network Virtualization,甚至可以给每一个Guest OS一个Physical Network Interface,这些都是可以的。但是对于Embedded & Real-Time System以及更高要求的Dependable System for embedded device,Synchronous IPC和Pager则是必须的。这个或许可以理解为什么Xen For Server, 而L4则可以开发基于Real-Time & Embedded的应用。虽然也有Real-Time Xen的Paper出现,但是如果要实现Real-Time Xen,那么有几个地方必须考虑更改,首先asynchronous IPC是不能够real-time guarantee的。但是如果实现基于L4的Server Virtualization,有一个大难题,就是Windows,没有L4可以支持多个Windows Instance,虽然有一些奇怪的办法可以做到Multi-Windows Instances (L4Linux + Qemu + Windows),但是这只是研究,工业应用完全行不通。关于L4与Xen复杂性的问题,其实差不多,Pistachio大概是2万行代码左右,OKL4 被精减到了1万3千行。 第二篇Paper是Gernot Heiser关于这篇Paper的一个defense,Gernot Heiser是OKL4的掌门人。Title完全一样,Are Virtual-Machine Monitors Microkernels Done Right? 因为是Defend,所以必须照单抓药,所以不像上面那一篇那么Systematic,所以我们挑最主要的列举如下: VMM的一些优点:software reliability(multi OS personality, one is dead others are still alive), data security (Good isolation could provide the security, At least the Virus of one OS can't infect the others ), Alternative system APIs (you don't need to change the OS API but change the VMM for the function updating sometimes)。 Microkernel的一些优点: Flexibility(L4 could be ported to different platforms and it can't depend on any hardware feature) , extensibility(you could implement many different OS personality based on the L4 and the high-level OS personality is independent from the low-level OS), fault isolation (the fault of one process can't cause the failure of whole system, it means that the protection granularity is less than the VMM, in VMM the protection is in the OS level), maintainability (it is easier to be maintained, I think the maintanability is not only the technology but also the engieering), restricted interdepedence(That means the dependency of one component could be restricted in some countable range). 以上关于是关于名词的一个解释,这个其实并不是那个数目多,那个就更好一些。软件的用户喜好并不是直接取决于设计,与很多方面有关,这个要看用户自己评估和具体需求。Gernot Hesier认为: it seems that the microkernel and VMMs share a common set of goals, but they take different approaches。既然是seems, 那就说they are not the same in pricinple. Microkernel的key point是minimality,但是因为VMM一般都比较好,所以基本上满足minimality的原则。 Core Primitives: Microkernel: 因为Microkernel是脱胎于Traditional Monolithic OS,所以IPC是core primitive,IPC有3个目标: 1)IPC用来控制protected domain之间控制信息的转移。 2)IPC用来控制protected domain之间数据信息的转移。 3)IPC用来控制protected domain(特别是多个distrust parties之间需要一个agreement的情况)之间资源托管。这一点似乎挺难理解,以后再专门解释。 以上三点是完全orthogonal(没有共同点),Microkernel就是综合以上3个方面,然后设计并优化。其他任何操作都可以通过这3中IPC 的组合来完成。从概念上来讲,似乎Microkernel还是很pure的。因为IPC不光是OS所应该提供的功能,然和集体性质的东西都应该存在 IPC,包括人类社会。 VMM: VMM是一些底层硬件资源的重新软件化,比如processor, memory, 各种Device,security mechanism等。所以VMM提供的core primitive比较多,不是很pure. 1)Guest Kernel到 Guest User的synchronous switch,Guest User到Guest Kernel的synchronous switch。 2)Domain之间的,Asychronous Communication. 3)Virtual Machie的Resource Allocation and Resource Allocation by VMM 4)Page Fault和Exception Handling by Exception Virtualization 5)Asychronous event notification by virtual-interrupt mechanism 6)hardware interrupt notification by virtualized interrupt controller 7)A set of common devices 因此,Xen就是一个Hardware Machine Multiplexer。对于每一个Virtual Machine,Xen就是下面的Hardware。因为VMM试图模拟硬件,所以几乎不需要对现有的操作系统作很多修改。更极端的比如VMWARE,根本不需要对OS作任何修改,就可以运行。但是,Xen因为需要更好地支持Legacy OS,所以必须对Guest OS作一些修改,这就是从Full Virtualization到Para-Virtualization的转变。接口的多样性导致可能产生新的Bug。其中,一个主要的问题,如果Xen 需要支持更多的新OS的话,那么Xen不可避免地增加某些新接口以适应新的OS。因为VMM是提供底层硬件的某一种层次的抽象,这个抽象层次至少是低于 Linux内核源代码目录中的ARCH的抽象的,因此,对于不同的硬件,所提供的接口应该是不同的。换而言之,VMM的设计应该不是能够Cross Platform的。但是,L4的设计是能够Cross Platform的,目前L4a可以支持到9种CPU,但是基本上可以保持一个统一的Interface。这个诘难似乎说到电子上了,因为按照VMM的本意,的确是不能够Cross Platform的。Xen里面Common目录的文件数量明显小于ARCH目录下面的文件数量。 Architecture Lessons: 1)Avoid Liability Inversion 这里的理解是说,moving the service out of kernel是模糊了Dependability的范围,换句话说,就是把本来能够限制在一个很小范围的错误可能扩散到更大的空间。Gernot Heiser使用了同样基于Xen的一个提供storage的系统,而这个系统,同样使用了一个User Space Pager(这是上面那篇Paper为了说明Liability Inversion而举的一个例子),这个Paper说他们这样作,可以Avoid Liability Inversion。这一点似乎可以驳倒。但是我觉得C/S不应当成为Microkernel OS的一个基本特性,正如我前面说说,C/S结构是SawMill Linux的特点。但不是Microkernel OS的特点。 2)Make IPC performance irrelevant 这一点很明显,因为Xen的观点是Domain Communication is less frequent。Gernot Hesier认为Xen在混淆概念,首先:Xen使用Domain0作为封装所有的Device,然后使用roundchip communcication between Guest OS and Domain0,并命名为“simple asychronous event mechanism",其实就是IPC。其次,就是用一些例子来证明Xen的IPC不是Fast的,而且Xen的IPC开销会比正常I/O的更大,依据就是Dom0的CPU Load和Xen的Page-flipping的数目是成比例的。还有一个,即使Xen是调度整个OS的,而不是调度OS里面的某个Task,但是即使这样,也不能认为他们不需要IPC,不需要内部交互。比如Guest OS Kernel Space和Guest OS User Space之间的交互,仍然是需要IPC来协调的。 3)Treat OS as a component 这里比较好玩,他以DROPS已经成形多年来辩护。不过这个我觉得根本不是重点,公说共有理,婆说婆有理。我说我的好,你说你的好。 Finally,Gernot Heiser Say no for this question "Are Virtual Machine Monitors Microkernels Done Right"。也就是说,他不承认VMM是个微内核,也不认可VMM is the microkernel done right. 对于我们而言,了解L4和Xen的不同,有助于我们更好地理解这2种系统,反正目前他们已经很像很像了,理解这些系统设计的出发点,理解他们的不同。如果我们需要开发一个新型OS,那么L4和Xen就是一个很好的Starting Point,但是前提是我们必须选择合适的东西。
撰写答案
登录
注册新账号
关注者
1
被浏览
4.8k
关于作者
bernard
这家伙很懒,什么也没写!
提问
414
回答
5940
被采纳
76
关注TA
发私信
相关问题
1
有关动态模块加载的一篇论文
2
最近的调程序总结
3
晕掉了,这么久都不见layer2的踪影啊
4
继续K9ii的历程
5
[GUI相关] FreeType 2
6
[GUI相关]嵌入式系统中文输入法的设计
7
20081101 RT-Thread开发者聚会总结
8
嵌入式系统基础
9
linux2.4.19在at91rm9200 上的寄存器设置
10
[转]基于嵌入式Linux的通用触摸屏校准程序
推荐文章
1
RT-Thread应用项目汇总
2
玩转RT-Thread系列教程
3
国产MCU移植系列教程汇总,欢迎查看!
4
机器人操作系统 (ROS2) 和 RT-Thread 通信
5
五分钟玩转RT-Thread新社区
6
【技术三千问】之《玩转ART-Pi》,看这篇就够了!干货汇总
7
关于STM32H7开发板上使用SDIO接口驱动SD卡挂载文件系统的问题总结
8
STM32的“GPU”——DMA2D实例详解
9
RT-Thread隐藏的宝藏之completion
10
【ART-PI】RT-Thread 开启RTC 与 Alarm组件
最新文章
1
【24嵌入式设计大赛】基于RT-Thread星火一号的智慧家居系统
2
RT-Thread EtherKit开源以太网硬件正式发布
3
如何在master上的BSP中添加配置yml文件
4
使用百度AI助手辅助编写一个rt-thread下的ONVIF设备发现功能的功能代码
5
RT-Thread 发布 EtherKit开源以太网硬件!
热门标签
RT-Thread Studio
串口
Env
LWIP
SPI
AT
Bootloader
Hardfault
CAN总线
FinSH
ART-Pi
USB
DMA
文件系统
RT-Thread
SCons
RT-Thread Nano
线程
MQTT
STM32
RTC
FAL
rt-smart
ESP8266
I2C_IIC
WIZnet_W5500
UART
ota在线升级
PWM
cubemx
freemodbus
flash
packages_软件包
BSP
潘多拉开发板_Pandora
定时器
ADC
GD32
flashDB
socket
中断
Debug
编译报错
msh
SFUD
keil_MDK
rt_mq_消息队列_msg_queue
ulog
C++_cpp
at_device
本月问答贡献
踩姑娘的小蘑菇
7
个答案
3
次被采纳
a1012112796
15
个答案
2
次被采纳
张世争
9
个答案
2
次被采纳
rv666
5
个答案
2
次被采纳
用户名由3_15位
13
个答案
1
次被采纳
本月文章贡献
程序员阿伟
9
篇文章
2
次点赞
hhart
3
篇文章
4
次点赞
大龄码农
1
篇文章
5
次点赞
RTT_逍遥
1
篇文章
2
次点赞
ThinkCode
1
篇文章
1
次点赞
回到
顶部
发布
问题
分享
好友
手机
浏览
扫码手机浏览
投诉
建议
回到
底部