kernel 2.6.29 と差し替えてみる

QEMU のサイトからダウンロードできる arm-test 0.2 の kernel を差し替えてみる。

http://www.nongnu.org/qemu/arm-test-0.2.tar.gz

kernel.org から最新の 2.6.29 を取ってくる。

http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2

クロスコンパイラは、結局 CodeSourcery から持ってきた。

http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite

VMWare 上に最低限の Debian 5.0.0 環境を作ってインストール (単に tarball を展開するだけでも OK)。
.bashrc に

export LANG=C
export ARCH=arm
export CROSS_COMPILE=arm-none-linux-gnueabi-
export PATH=/path/to/CodeSourcery/Sourcery_G++_Lite/bin:$PATH

ARCH が大文字じゃないと駄目なので注意（参考サイト [1] では小文字になっててはまった…）。

参考サイト

[1] http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu
[2] http://d.hatena.ne.jp/himainu/20080430

$ cp arch/arm/configs/versatile_defconfig .config
$ make menuconfig

Enable DHCP Support (CONFIG_IP_PNP_DHCP).

Networking -> Networking Support -> Networking Options -> TCP/IP Networking ->

Enable Universal Tun/Tap Driver Support (CONFIG_TUN)

Device Drivers -> Network Device Support ->

Enable ARM EABI Support (CONFIG_AEABI)

Kernel Features ->

Enable tmpfs support (CONFIG_TMPFS)
File Systems -> Pseudo File Systems ->

Enable PCI (CONFIG_PCI)

SCSI LOW level drivers -> CONFIG_SCSI_SYM53C8XX_2

$ make

できた arch/arm/boot/zImage を持ってきて、arm-test 以下に置いたと仮定して。

$ qemu-0.9.1/arm-softmmu/qemu-system-arm.exe -M versatilepb -kernel arm-test/zImage -initrd arm-test/arm_root.img

で起動した。ちょっとフォントが変だけど…

machine number

Linux Kernel は、ブートローダの中でマシンチェックを行っているので、r1 レジスタに適切な machine number を入れておかないとブートできない。

http://www.arm.linux.org.uk/developer/machines/

を見ると ARM Versatile Porting Board (versatile_pb) は 387 と書いてある。

QEMU の hw/versatilepb.c を見ると、vab_init() の中で versatile_init() の最後の引数に 0x183 を指定して呼び出している。まさしく 0x183 = 387。

というわけで、マジックナンバーの謎が解けた。linux kernel のロードのための引数だったのね。static

void vpb_init(int ram_size, int vga_ram_size,
                     const char *boot_device, DisplayState *ds,
                     const char *kernel_filename, const char *kernel_cmdline,
                     const char *initrd_filename, const char *cpu_model)
{
    versatile_init(ram_size, vga_ram_size,
                   boot_device, ds,
                   kernel_filename, kernel_cmdline,
                   initrd_filename, cpu_model, 0x183);
}

...

QEMUMachine versatilepb_machine = {
    "versatilepb",
    "ARM Versatile/PB (ARM926EJ-S)",
    vpb_init,
};

QEMU stdvga

http://hrb.osask.jp/wiki/?advance/QEMUVGA

vl.c の中でオプション解析。デフォルトは cirrus_vga_enable になってるみたい。

pci/isa_vga_init() で作ったビデオカードが stdvga 相当になるみたい。

（他はそれぞれ、vga の代わりに cirrus  や vmsvga が付いた初期化関数を使う）

QEMU base emulator

Bishop エミュレータ

やはりこの会社は、Android もやってるみたい。

parent_irq

QEMU の仮想デバイス (例えば i8259) には、parent_irq というメンバーが存在することが多い。

これにより、複数のデバイスの IRQ を繋げることができるようだ。なるほど、よくできてる。

大抵は、初期化の時に cpuirq などの、CPU と直結する IRQ （ハンドラの中で cpu_interrupt() を呼ぶ） を作っておいて、これをトップレベルの parent_irq とする。

ldl_code の続き

grep しても見つからないわけだ。disas_arm_insn 内の ldl_code の正体は、例のこれ。

#define ACCESS_TYPE (NB_MMU_MODES + 1)

#define MEMSUFFIX _code

#define env cpu_single_env

#define DATA_SIZE 1

#include "softmmu_header.h"

#define DATA_SIZE 2

#include "softmmu_header.h"

#define DATA_SIZE 4

#include "softmmu_header.h"

#define DATA_SIZE 8

#include "softmmu_header.h"

#undef ACCESS_TYPE

#undef MEMSUFFIX

#undef env

#endif

これで、softmmu_header.h 内の

/* generic load/store macros */

static inline RES_TYPE glue(glue(ld, USUFFIX), MEMSUFFIX)(target_ulong ptr)

{

    int index;

    RES_TYPE res;

    target_ulong addr;

    unsigned long physaddr;

    int mmu_idx;

    addr = ptr;

    index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);

    mmu_idx = CPU_MMU_INDEX;

    if (__builtin_expect(env->tlb_table[mmu_idx][index].ADDR_READ !=

                         (addr & (TARGET_PAGE_MASK | (DATA_SIZE - 1))), 0)) {

        res = glue(glue(__ld, SUFFIX), MMUSUFFIX)(addr, mmu_idx);

    } else {

        physaddr = addr + env->tlb_table[mmu_idx][index].addend;

        res = glue(glue(ld, USUFFIX), _raw)((uint8_t *)physaddr);

    }

    return res;

}

これが tatic inline uint32_t  ldl_code(target_ulong ptr) に特殊化される。

/* generic load/store macros */

static inline uint32_t ldl_code(target_ulong ptr)

{

    int index;

    uint32_t res;

    target_ulong addr;

    unsigned long physaddr;

    int mmu_idx;

    addr = ptr;

    index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);

    mmu_idx = CPU_MMU_INDEX;

    if (__builtin_expect(env->tlb_table[mmu_idx][index].ADDR_READ !=

                         (addr & (TARGET_PAGE_MASK | (DATA_SIZE - 1))), 0)) {

        res = __ldl_cmmu(addr, mmu_idx);

    } else {

        physaddr = addr + env->tlb_table[mmu_idx][index].addend;

        res = ldl_raw((uint8_t *)physaddr);

    }

    return res;

}

考えてみれば当たり前。全ての (QEMU 上の仮想 RAM への) メモリアクセスは (QEMU の仮想) MMU 経由で行わないといけないのだから。

disas_arm_insn

target-arm/translate.c の

static void disas_arm_insn(CPUState * env, DisasContext *s)

{

    unsigned int cond, insn, val, op1, i, shift, rm, rs, rn, rd, sh;

    insn = ldl_code(s->pc);

ここで s->pc は、ロードされたターゲットのマシン語の pc だ。

cpu-all.h を見ると。

#define ldl_code(p) ldl_raw(p)

#define ldl_raw(p) ldl_p(laddr((p)))

#define laddr(x) (uint8_t *)(long)(x)

#define ldl_p(p) ldl_le_p(p)  /* !defined(TARGET_WORDS_BIGENDIAN)  */

static inline int ldl_le_p(void *ptr)

{

    return *(uint32_t *)ptr;

}

う～ん、なぜこれで命令が取ってこれるのかよくわからない。

メモリのどこに、ターゲットの命令はロードされてるんだ ?

たぶん phys_ram_base とかだと思っていたんだけど、違うのかな ?

追記

これは CONFIG_USER_ONLY 版のコードなので、全く関係無かった。

しかし、どこに定義があるんだ… grep した限りでは見つけられなかった。

cpu_index

exec.c の cpu_exec_init() を見ればわかるけど、全ての cpu_init()  (実体は cpu_arm_init() などの define) で作った CPU　(実体は target/ 以下の struct CPUARMState など) は、全てグローバル変数 first_cpu から作った順番に辿ることができる。

最初の CPU が cpu_index == 0 で、順番に全て番号が付いているので、番号で識別できる。

cpu_single_env も似たような感じに使われているけど、これは cpu-exec.c の cpu_exec 関数の内部だけで有効。

686    /* fail safe : never use cpu_single_env outside cpu_exec() */

687    cpu_single_env = NULL;

688    return ret;

689}

ここらへんからも、QEMU はマルチスレッド対応が考えられていないことがわかる。

/* 'pc' is the host PC at which the exception was raised. 'address' is

   the effective address of the memory exception. 'is_write' is 1 if a

   write caused the exception and otherwise 0'. 'old_set' is the

   signal set which should be restored */

static inline int handle_cpu_signal(unsigned long pc, unsigned long address,

                                    int is_write, sigset_t *old_set,

                                    void *puc)

{

    TranslationBlock *tb;

    int ret;

    if (cpu_single_env)

        env = cpu_single_env; /* XXX: find a correct solution for multithread */

cpu_interrpt() is probably not threadsafe.

う～む。

/* mask must never be zero, except for A20 change call */

void cpu_interrupt(CPUState *env, int mask)

{

。。。

    /* FIXME: This is probably not threadsafe.  A different thread could

       be in the middle of a read-modify-write operation.  */

    env->interrupt_request |= mask;

#if defined(USE_NPTL)

    /* FIXME: TB unchaining isn't SMP safe.  For now just ignore the

       problem and hope the cpu will stop of its own accord.  For userspace

       emulation this often isn't actually as bad as it sounds.  Often

       signals are used primarily to interrupt blocking syscalls.  */

#else

       。。。

}

QEMU internal timer interrupts

cpu_exec の内部では、TB (TranslationBlock) の実行ループが延々と行われている （TB には、ブレークポイントやジャンプ命令は入っていないので、無限ループを実行中でも必ず止まる。止まっては、また実行し、の繰り返し）。

しかし、これだけでは、仮想 CPU の上でエミュレートしている外部ペリフェラル （= 実行中のプログラム） などから割り込みが入らない限り、QEMU の内部の時間を進めることができなくなってしまう。

そこで QEMU は、自ら定期的に割り込み （CPU_INTERRUPT_EXIT） を CPU に入れることにより、cpu_exec 内部の TB （JIT 済みのコード）実行ループから抜けているようだ。これで、QEMU 内部の時間が進み、様々な内部処理を一定間隔で行うことが可能になる。

つまり、TB チェーンの実行を繰り返す小さなループと、定期的に割り込みをチェックして、割り込み要因に合わせて CPU の状態を変化させるための大きなループの、2 つのループが回っている。

exec.c に以下のようなコメントがある。

        /* CPU_INTERRUPT_EXIT isn't a real interrupt.  It just means

           an async event happened and we need to process it.  */

大きいほうのループを動かすため、小さいほうのループに定期的に割り込みを入れる際には、Windows のマルチメディアタイマーを使用しているようだ。

Windows 対応 patch の開発者の方のブログ記事。

http://blogs.dion.ne.jp/kazuu/archives/2544632.html

http://blogs.dion.ne.jp/kazuu/archives/3127029.html

（核心部分）

http://blogs.dion.ne.jp/kazuu/archives/3132263.html

このほかにもたくさん参考になる記事があって、ゲスト OS の時計の進め方を正確にしようと思うと、非常に大変ということがよくわかる。

vl.c を使う （普通に QEMU システム全体を使う） 場合は考えなくても良いけど、仮想 CPU ライブラリ (libqemu.a） の部分だけを使う場合は、ここらへんも考えないとちゃんと動かない。

ちょっと気になった記事。デバッガと繋げる際のはまりポイント。

http://blogs.dion.ne.jp/kazuu/archives/3890764.html

trunk

QEMU の Subversion から trunk (6292)  を取ってきたら、cc も host-cc も共に、 gcc 3 系列でも 4 系列でも無修正でビルド通って、正常に動いているようだ。素晴らしい。

$ svn co svn://svn.sv.gnu.org/qemu

$ cd ..

$ mkdir build

$ cd build

$ i686-pc-mingw32-gcc-4.3.2.exe -v

Using built-in specs.

Target: i686-pc-mingw32

Configured with: ../gcc-4.3.2/configure --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --enable-languages=c,c++ --enable-threads --disable-nls --disable-win32-registry --disable-shared --without-x --enable-hash-synchronization --enable-libstdcxx-debug --enable-version-specific-runtime-libs --without-included-gettext --disable-bootstrap --disable-libssp --disable-libstdcxx-pch

Thread model: win32

gcc version 4.3.2 (GCC)

$ ../trunk/configure --cc=i686-pc-mingw32-gcc-4.3.2.exe --host-cc=i686-pc-

mingw32-gcc-4.3.2.exe --target-list=arm-softmmu

$ make

$ cd ..

$ wget http://bellard.org/qemu/arm-test-0.2.tar.gz

$ tar zxvf arm-test-0.2.tar.gz

$ cd arm-test

$ ../build/arm-softmmu/qemu-system-arm.exe -kernel zImage.integrator -initrd arm_root.img

softmmu_template

template というから、なんか自動生成しているのかと思っていたら、何のことは無かった。

単にプリプロセッサで切り替えているだけだった。

exec.c の一番最後。

#if !defined(CONFIG_USER_ONLY)

#define MMUSUFFIX _cmmu

#define GETPC() NULL

#define env cpu_single_env

#define SOFTMMU_CODE_ACCESS

#define SHIFT 0

#include "softmmu_template.h"

#define SHIFT 1

#include "softmmu_template.h"

#define SHIFT 2

#include "softmmu_template.h"

#define SHIFT 3

#include "softmmu_template.h"

#undef env

#endif

softmmu_template.h

#define DATA_SIZE (1 <<>

#if DATA_SIZE == 8

#define SUFFIX q

#define USUFFIX q

#define DATA_TYPE uint64_t

#elif DATA_SIZE == 4

#define SUFFIX l

#define USUFFIX l

#define DATA_TYPE uint32_t

#elif DATA_SIZE == 2

#define SUFFIX w

#define USUFFIX uw

#define DATA_TYPE uint16_t

#elif DATA_SIZE == 1

#define SUFFIX b

#define USUFFIX ub

#define DATA_TYPE uint8_t

#else

#error unsupported data size

#endif

要するに、0 が byte (uint8_t)、1 が word (uint16_t)、2 が long (uint32_t)、3 が quad word (uint64_t) ということらしい。

#if SHIFT <= 2

    io_mem_write[index][SHIFT](io_mem_opaque[index], physaddr, val);

みたいになっていて、0-1 (byte,word,long) それぞれのハンドラがコールされる。なるほど。

quad word の場合は、エンディアンに合わせて long (io_mem*[2]) のハンドラを 2 回コール。

global variables

io メモリの実体は exec.c に。

CPUWriteMemoryFunc *io_mem_write[IO_MEM_NB_ENTRIES][4];

CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][4];

void *io_mem_opaque[IO_MEM_NB_ENTRIES];

物理メモリの実体は、ポインタが exec.c にあって、

int phys_ram_size;
uint8_t *phys_ram_base;

vl.c で確保される。

    /* init the memory */

    phys_ram_size = ram_size + vga_ram_size + MAX_BIOS_SIZE;

    phys_ram_base = qemu_vmalloc(phys_ram_size);

qemu_vmalloc(size) は osdep.c で定義されており、Windows の場合は VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE) が使われる。

io_memory

cpu_register_io_memory が返す整数値は、io メモリ配列の index に関連付けられたディスクリプタ

int cpu_register_io_memory(int io_index,

                           CPUReadMemoryFunc **mem_read,

                           CPUWriteMemoryFunc **mem_write,

                           void *opaque)

{

    int i, subwidth = 0;

    if (io_index <= 0) {

        if (io_mem_nb >= IO_MEM_NB_ENTRIES)

            return -1;

        io_index = io_mem_nb++;

    } else {

        if (io_index >= IO_MEM_NB_ENTRIES)

            return -1;

    }

    for(i = 0;i <>

        if (!mem_read[i] || !mem_write[i])

            subwidth = IO_MEM_SUBWIDTH;

        io_mem_read[io_index][i] = mem_read[i];

        io_mem_write[io_index][i] = mem_write[i];

    }

    io_mem_opaque[io_index] = opaque;

    return (io_index <<>

}

io_index を IO_MEM_SHIFT ぶん右シフトしたものが、io_mem* 配列の index になる。