vm-kernel

经过几天的debug，在很多地方加入 判断是否有SIG pending的语句，结果都是没有信号pending。那么唯一的可能就根本没有产生SIGALRM信号！ 继续追踪。Qemu中提供了很多中定时器的实现方法，见数组alarm_timers。

1: static struct qemu_alarm_timer alarm_timers[] = {

2: #ifndef _WIN32

3: #ifdef __linux__

4: {"dynticks", ALARM_FLAG_DYNTICKS, dynticks_start_timer,

5: dynticks_stop_timer, dynticks_rearm_timer, NULL},

6: /* HPET - if available - is preferred */

7: {"hpet", 0, hpet_start_timer, hpet_stop_timer, NULL, NULL},

8: [...]

那在qemu中，有一个gui timer会定时刷新gui的信息。现在gui的tile没有变化，就说明这个gui timer 根本没有被触发。
而在qemu中的定时器是通过函数host_alarm_handler来触发运行的，函数host_alarm_handler又是通过信号来进行触发的。那么问题的根源就是信号没有被发送或者被block(还没有查出具体原因)。
我尝试在终端中向qemu发生SIGALRM信号，果然，qemu接收到SIGALRM信号后，执行host_alarm_handler然后会执行所有注册了的定时器的超时函数(包括display_state.gui_timer)。
kill-bill: # ps aux | grep qemu
root      2945  101  3.2 196468  8404 pts/1    R+   09:36   0:14 ./qemu-system-arm -M beagle -mtdblock beagle-nand.bin
root      2947  0.0  0.2   2996   692 pts/0    R+   09:36   0:00 grep qemu
kill-bill: # kill -s SIGALRM 2945

多次发送SIGALRM信号后，qemu可以正常接受终端的输入。下面是qemu运行u-boot的截图。

接下来就需要查找为什么qemu没有收到SIGALRM！

x-load 已经可以在qemu-omap3中运行起来。对x-load主要做了两个地方的修改:
1. 对判断外部输入时钟频率的部分，做了修改。x-load判断外部时钟频率的方法是先设置32KHZ的基准时钟，然后设置GP1的时钟源为SYS_CLK。然后读取GP1 Timer在20个cycle内的差值，进而判断时钟。这个方法在emulator中有的时候并不是很准。因为emulator除了执行指令外，还需要做其他事情。有的时候，emulator去读取GP1 Timer 的时候，实际上运行的时间已经不止ARM 20个cycle的时间，因此读取出来的counter值偏大。而x-load仍然认为刚才是跑了20个cycle。因此，得到的频率比实际的频率大。在 qemu-omap3中，目前认为外部时钟的频率是12MHZ13MHZ,因此，去掉了x-load中判断外部时钟频率的部分，在x-load中直接赋值外部时钟频率12MHZ13MHZ.
2. 去掉了nand flash中进入ECC检查的部分。也就是注释掉drivers/k9f1g08r0a.c中的宏ECC_CKECK_ENABLE

//57 #define ECC_CHECK_ENABLE

下面是x-load运行的信息：

# ./qemu-system-arm -M beagle -mtdblock beagle-nand.bin -serial stdio -nographic

Texas Instruments X-Loader 1.41

Starting OS Bootloader...

运行到u-boot的时候还有点问题。go on working.

ARM和MIPS都是Load-store结构，也就是说CPU只处理寄存器中的数据，而不会直接去处理memory中的数据。要想处理memory中的数据，必须先把memory中的数据load到寄存器中。
那如何load一个32bit的立即数到寄存器中呢？我们知道，ARM和MIPS的指令长度都是32bit，也就是说，不可能用一条指令来直接load一个32bit数据到寄存器中（如果可以的话，数据占了32bit，指令该如何编码？）
ARM中采用了ldr指令来实现这个功能。

LDR {cond} <Rd>,<addressing mode>

ldr 指令将一个memory中的数据load到寄存器Rd中。因此，如果需要load一个32bit立即数的话，先在memory中存放这个数据，然后调用 ldr指令来load这个数据到寄存器中。参考下面的代码中Line3。为了load 0x49020000到r0中，先在地址0x40202428中存入这个立即数，然后在调用ldr将这个数load到寄存器中。

1: 40202418 <serial_getc>:

2: 40202418: e52de004 push {lr} ; (str lr, [sp, #-4]!)

3: 4020241c: e59f0004 ldr r0, [pc, #4] ; 40202428 <serial_getc+0x10>

4: 40202420: eb000042 bl 40202530 <NS16550_getc>

5: 40202424: e49df004 pop [...]

在LDD3上有一个例子，代码如下：

1: /* Wait for space for writing; caller must hold device semaphore. On
2: * error the semaphore will be released before returning. */
3: static int scull_getwritespace(struct scull_pipe *dev, struct file *filp)
4: {
5:
6: while (spacefree(dev) == 0)

7: { /* [...]

讨论见这里：http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00144.html
Fabrice 的回复：http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00149.html
这里还有qemu 中3D加速的讨论：http://www.mail-archive.com/qemu-devel@nongnu.org/msg15702.html

上一篇文章中，介绍了如何在google code中使用Git svn。现在又有了新问题。比如项目qemu-omap3是想往开源项目qemu中增加一个新的功能。qemu-omap3的项目hosting是在google code上面，使用Git svn来管理。而qemu在http://repo.or.cz/w/qemu.git，使用Git来管理。
为了开发qemu-omap3，需要从某一天的qemu中拿下来所有的源码，然后在这个基础上进行开发。但问题在于qemu的开发也同时在进行。这就需要qemu-omap3中的代码能保持和qemu中的同步。也就是说，我的需求如下：
1.  使用git svn来管理qemu-omap3
2. 能得到最新的qemu的代码
3. 最新的qemu的代码不影响我的qemu-omap3

之前解决的方法是定期从qemu中拿下所有的源码，然后在qemu-omap3中建立一个branch，然后拷贝过去，进行merage。这个过程比较繁琐。
实际上，可以通过git remote命令来增加一个新的remote repo。
git remote add qemu http://repo.or.cz/r/qemu.git
git fetch qemu

这会在git中自动建立一个branch qemu并且会将所有的qemu中的branch等全部放到qemu下。下面是目前我的branch。
kill-bill:/home/root/sdc/qemu/qemu-omap/svn# git-branch -a * master   qemu/master   qemu/svn/perso   qemu/svn/tags/initial [...]

x-load本质是一个U-BOOT的精简版。为什么需要x-load这个玩意呢，而不是直接用u-boot呢？那是因为U-boot太大了，塞不进内部的RAM？那为啥要把X-LOAD塞进内部的RAM，而不是load到外部的RAM呢？
问题就在这里了。当OMAP3530上电的时候，memory controller还没有初始化，怎么去读写外部的RAM呢？必须要有人能先初始化memory controller啊。任务就交给x-Load了。它必须负责初始化外部的RAM控制器，把u-boot从NAND或者MMC中读出到外部RAM，然后跳到u-boot的入口处执行。
问题又来了，那么x-load又是由谁来load的呢？OMAP3530里面带了一个内部RAM，大小为64K。当OMAP3530上电后，会从NAND Flash或者MMC中读取x-load到内部的RAM。然后执行x-load，x-load然后执行上面所说的任务，最后把控制入口交给u-boot。
要编译x-load，先安装toolchain。然后
In file include/configs/omap3530beagle.h
/* For X-loader to be flashed on to NAND disable the below macro */ //#define CFG_CMD_MMC Comiple the x-loader as shown below make CROSS_COMPILE=arm-none-linux-gnueabi- distclean make CROSS_COMPILE=arm-none-linux-gnueabi- omap3530beagle_config [...]

相比sf，googlecode的使用更加简单和方便。虽然在功能方面没有sf多，但是对于一个开源项目来说，基本上够用了。google code的功能有wiki，下载，svn，issue report。最近googlecode的svn中又增加了一个code review的功能，也就是说别人可以浏览SVN中代码并且留下comment。详细见google的介绍：http://code.google.com/p/support/wiki/CodeReviews
虽然google提供的SVN功能不错，但是我喜欢在本地用GIT来管理我的代码。之前我的使用方法是用svn co下来一份代码，然后git建一个本地仓库，所有的代码修改log都进入本地仓库。当完成一个功能后，用svn commit进googlecode。这样做的缺点在于本地git的log不能反应到svn中。也就是说svn中的log信息都是比较粗线条的，不能很细化的反应项目的变化情况。
于是就需要请出我们今天的主角：git-svn。首先在ubuntu中安装它。
sudo apt-get install git-svn

    安装完以后，需要checkout出google code svn中的东西来。
git-svn clone https://omap3emu.googlecode.com/svn -T trunk -b branches -t tags

这会在本地生成一个文件夹svn。里面就是google code svn中的东西。请记住，GIT的远端仓库和本地目录都是在一起的。我们来看一下目前的GIT仓库中有哪些branch。

目前以shared source发布的device emulator的版本是v1，我手头的版本也就是这个版本。在MSDN的这篇文章中，Barry给出了device emulator的V2版本对于V1的改进的地方。通过这些改进，模拟速度的提升达到40%!
1. TLB 查找的优化
我们知道在带有MMU的ARM中，当访问memory的时候，需要先将虚拟地址转换成物理地址。这涉及到查TLB和页表的过程。如果能在TLB中找到表项，则不用去页表中进行查找。
在V1中，实现了TLB的查找。整个TLB的表项有64个。在硬件实现中，TLB的查找是并行的，而对于emulator来说，查找是线性的。最坏的情况需要遍历整个64个entry。因此，如果能够快速的寻找到TLB表项，无疑对于性能是一个很大的帮助。
根据程序的memory访问具有相关性(locality)的特点（也就是说，下一次访问的memory地址和上一次访问的memory地址不会相差太远），因此，在进行TLB查找的时候，总是从上一次查找成功的那个TLB Slot开始查找，而不是从TLB 表项0开始查找。
但这仍然有一个问题，最坏的情况下，仍然是线性搜索64个entry。V2做了一个改进，将线性的搜索变为hash搜索。这样，在最坏的情况下，不用遍历整个64个entry。不过具体的hash算法并没有给出。
2. Interrupt polling
这个也比较有意思。对于emulator来说，interrupt的产生是异步的，因此emulator是需要不断polling interrupt的状态。如果有interrupt pending，必须修改guest的PC,使得guest跳到异常处理程序的地方继续执行。
根据我之前开发emulator的经验，会在emulator的JIT生成的X86汇编中阶段性的去polling interrupt的状态。比如

if (g_fInterruptPending) {
SimulateHardwareInterrupt();
}

也就是说，JIT生成的X86代码需要非常多的MOV/CMP/BRANCH的序列。而在V2中，将interrupt polling 改成

void SimulateHardwareInterruptIfPending(void)
{ /* note: no code here */
}

这个函数是一个空函数。让有中断产生的时候，会patch这个函数，将这个函数变成RET到中断处理函数的地址。 这样就可以省掉MOV/CMP/BRANCH的序列。其实还可以减少translated后的代码大小。
3. 优化memcpy和memset.
emulator能识别出guest的memcpy和memset，把它变成手工优化的X86代码。
如何识别memcpy和memset，没有讲明。我想应该和所使用的 libc库以及compiler有关。
4. 窥孔优化
对IR进行窥孔优化。

str r0, [sp+10]
ldr r3, [sp+10]

变成

str r0, [sp+10]
mov r0, r3
5. 一次尽可能多的去ARM指令
也就是一次去指令的时候，至少应该可以取1K的指令。而不用每一次取指令的时候都去跑完整个memory load(guest虚拟地址->TLB->[页表->]guest物理地址->host虚拟地址->取指令)的整个过程。这个优化方法在dynamips和virtualmips中也有应用。
6. Reduce x86 processor stalls due to mixed code and data
这个应该是X86处理器相关的。不具体介绍了。
其实这些优化方面都不是很难，但是取得的性能提升确实显著的:40%。看来我要多学学怎么用工具来寻找程序的瓶颈，如何去优化。特别对于emulator来说，性能是非常非常关键的。