vm-kernel

计划一个新的项目omap3emu:OMAP3的emulator。

等会等会，怎么又要做一个emulator啊？现在的emulator已经够多的了。

确实。qemu，skyeye，armware都有非常不错的ARM支持。其中以qemu的支持最为广泛。那么为什么还需要omap3emu呢？

1. 虽然已经有蛮多的ARM Emulator，但是，还没有能模拟ARM V7架构的Opensource的emulator。

2. 在上一篇文章中也提到，通过这个模拟器，可以进一步熟悉了解ARM的体系结构，为Lguest移植到ARM打下基础。我认为，学习一个新的体系结构最好的方法就是写一个emulator。

3. QEMU的执行速度虽然很快，但是由于其采用了JIT的方法来生成代码，导致不能了解每一步的代码执行情况，或者说debug的时候，比较困难。而 omap3emu打算先提供一个step by step的解释型的执行引擎，虽然很慢，但是对于调试emulator本身和上面的软件都是比较方便的。

4. 打算通过这个omap3emu来验证<虚拟机-系统与进程的通用平台>中介绍的各种优化方法到底有多大的用途，能获得多大的性能提升。在目前硬件发展越来越快的今天，也许其中所介绍的优化方法已经不再适用。

5. omap3emu作为移植lguest到OMAP3上面的前期工具。

6. 3D虚拟化方面的尝试。目前，多数的Emulator对于显卡的处理方式多为模拟。尝试采用虚拟化的方式来加速emulator中guest的3D/2D应用。 GUEST 3D/2D Application -- 虚拟化 -- host的3D加速。

omap3emu需要能在Linux和XP上运行，采用SDL作为LCD的模拟。编译系统采用scons。

编译器:  Linux：gcc  XP: VS2008 Express edition

项目的主页在googlecode上面。

目前的重点还是放在了qemu-omap3上面。从头开始做omap3emu 所需要的时间/精力太大。不是我目前能承受的。

最近几天一直在分析device emulator的源代码(采用Share Source发布)。为了看一下其运行的效果，因此打算编译运行device emulator。

首先下载device emulator。 下载地址

在device emulator的doc中给出了编译的方法。

首先需要下载 zlib-1.2.3，解压后放到features\zlib中，然后下载 libpng 1.2.8，解压到 features\libpng中。

推荐的编译环境是vs2005。编译的过程很简单，图形化的用户界面。编译完成后会在release中生成DeviceEmulator.exe。

下载 Windows Mobile 5.0 Emulator Images for Smartphone，用MSI文件提取器提出其中的BIN文件。文件在目录 Windows Mobile 5_EXT\Windows Mobile 5.0 Emulator Images for Smartphone - CHS\Deviceemulation\0804下。分别为 SP_CHS_GSM_QVGA_VR.bin和SP_CHS_GSM_VR.bin。搞不清楚这个两个文件有什么区别。

Read more...

1. qemu

http://bellard.org/qemu/

首先当然是大名鼎鼎的qemu了。Qemu目前能支持的指令集包括ARM/MIPS/PPC/X86等等。最新的版本是发布于2008年1月6日的0.9.1。对于ARM来说，目前的SVN的版本中(2008-10-07)支持的SOC/machine包括:

• integratorcp: ARM Integrator/CP (ARM926EJ-S)
• versatilepb: ARM Versatile/PB (ARM926EJ-S)
• versatileab: ARM Versatile/AB (ARM926EJ-S)
• realview: ARM RealView Emulation Baseboard (ARM926EJ-S)
• akita: Akita PDA (PXA270)
• spitz: Spitz PDA (PXA270)
• borzoi: Borzoi PDA (PXA270)
• terrier: Terrier PDA (PXA270)
• cheetah: Palm Tungsten|E aka. Cheetah PDA (OMAP310)
• n800: Nokia N800 tablet aka. RX-34 (OMAP2420)
• n810: Nokia N810 tablet aka. RX-44 (OMAP2420)
• lm3s811evb: Stellaris LM3S811EVB
• lm3s6965evb: Stellaris LM3S6965EVB
• connex: Gumstix Connex (PXA255)
• verdex: Gumstix Verdex (PXA270)
• mainstone: Mainstone II (PXA27x)
• musicpal: Marvell 88w8618 / MusicPal (ARM926EJ-S)
• tosa: Tosa PDA (PXA255)

从上面可以看出，qemu支持了非常多的ARM board。在执行效率方面，qemu采用了JIT的技术，因此，执行的速度比较快。曾经有报道说，在Athlon 64 3800+上，qemu上模拟Linksys NSLU2的效率比真正的硬件快20%[1]。

在目前已经release的版本中，qemu的动态翻译技术实际上是巧妙的利用了gcc来完成中间语言到host代码的翻译工作，也就是说其代码生成器是借助于gcc的。因此，qemu有对gcc版本的依赖。目前来说，推荐使用gcc3来编译运行qemu。对于gcc4的编译器，是不能成功用来编译运行qemu的。Qemu的动态翻译框架可以参考 [2][3]。

为了解决qemu依赖于编译器这个问题，必须要将原本gcc所做的代码生成器工作交由新的代码生成器来进行（看来投机取巧还是要付出代价的）。因此在目前SVN版本的qemu中引进了TCG(Tiny code generator)。这是一个将中间代码翻译成host指令的工具。比如ARM->中间语言->X86。后一步正是由TCG完成的。对于每一个不同的host，都必须有相应的翻译代码。也就是说TCG必须被移植到每一种支持的host。不过采用了TCG以后，可以对生成的basic block进行一定的优化，这是比原来的dyngen方式改进的地方[4]。

图片来自 http://www.aurel32.net/info/debian_arm_qemu.php

Read more...

写一个 from emulation to virtualization 的文章的计划很早就在我的大脑中盘旋。可是要写这样的一个文章，需要比较深的积累。

之前在尝试移植lguest到MIPS平台，虽然后来放弃了这个努力，但是仍然积累了一些经验。同时也明白，要想写一个virtualization之类的东西，对于ARM/MIPS的深刻了解是必不可少的。

在选择ARM还是MIPS作为文章的平台上，一直在考虑和权衡。最终还是选择ARM。这是因为(1)我想做的是嵌入式的virtualization，而 ARM又是嵌入式和手持设备中使用最为广泛的平台。（2）我对ARM平台还不是非常了解，而借此机会，可以深刻了解ARM平台。而不仅仅把自己局限在 MIPS平台上。从目前我了解的情况来看，MIPS相比ARM比较简单。而ARM的设计更为复杂，也更为灵活。不仅仅是单纯的RISC的理念。

为了实现这个目标，大约分为以下几个步骤进行。

1. 写一个解释型的ARM SOC的模拟器。目标:深刻理解ARM结构
2. 验证书上所提到的emulation的优化方法进行优化，得出每一种优化的效率。并做整理。作为短期目标的文章发布。
3. JIT。目标是移植一个通用的JIT框架。从ARM->中间表示->优化->host。而这一部分也可以写一些文章。
4. 移植lguest到ARM中。在这一过程中，需要权衡每一种设计方案，比较在ARM中设计虚拟化和X86的不同。
5. 在lguest中运行一些benchmark，看看有哪些可以优化的地方。
6. 仿照INTEL VT对ARM的指令集进行扩展

由于实现的模拟器的作用是用来作为example，因此，该模拟器的结构不要太复杂，代码量不要太大。基本上在1W行以内( 不包括JIT部分)。

模拟器的SOC初步定为OMAP3系列。原因在于有良好的文档和工具。模拟的板子为beagle borad，以后可以加入V哥的OPENOMAP。DSP扩展和3D加速的模拟作为低优先级任务。

整个计划的时间大约在6个月左右。也就是2008-10到2009-3月左右。