QEMU CPU建模完全指南：从TCG原理到新增指令集实战

如果你接手过CPU验证或者想在未流片的处理器上提前跑Linux，迟早会撞上QEMU的CPU建模。这活说简单不简单，说难也并不是无从下手——它不像写普通模拟器那样“取指、译码、执行”三步循环就完事，QEMU背后是一整套从指令解码、TCG中间码生成、host端代码翻译到翻译块缓存管理的流水线。把这条流水线的骨架看清楚，再往里面填你自己的指令集，效率会高非常多。这篇文章我会从底层原理、代码结构、实操流程、调试方法和性能优化几个维度拆解，尽量用我实际踩坑的经验来讲，适合想给QEMU新增CPU架构、想深入理解QEMU CPU模型、或者正在做自定义指令集模拟验证的工程师参考。

1. QEMU CPU建模的整体框架与核心原理

1.1 QEMU不是“一条指令一条指令”模拟的

很多人第一次接触QEMU的CPU模拟时，会下意识地把它理解成经典的“解释器”：读一条指令，做一个switch-case，更新寄存器，再读下一条。早期模拟器确实是这么干的，但QEMU不是。QEMU的核心是TCG（Tiny Code Generator），全称“微型代码生成器”。

TCG做的事情一句话概括：把guest（被模拟的CPU架构）的指令翻译成host（运行QEMU的真实CPU架构）能执行的原生代码，然后直接在一块缓存里执行。

举个例子，如果你在x86主机上用QEMU模拟一个ARM处理器，guest是一条ADD R0, R1, R2，QEMU不会在运行时去解析这条指令再模拟寄存器加法，而是先把这条ARM指令翻译成一段x86原生指令，缓存起来，下一次执行直接跳转到缓存里跑原生指令。这样一来，指令的执行开销从“解释+模拟”变成了“翻译一次、执行多次”，性能自然高出一大截。

这个“翻译缓存”在QEMU源码里叫TranslationBlock，通常缩写为TB。它不像Linux的page cache那样完全按页分割，而是以基本块为单位——也就是一条跳转指令或一个基本块结束标志为边界。你写CPU建模代码时，最重要的两个概念就是translate（翻译）和exec（执行），翻译阶段负责把guest指令变成TCG中间指令，执行阶段再由TCG后端把中间指令变成host原生指令。

1.2 核心数据结构：CPUState、CPUClass与CPUArchState

在QEMU里建模CPU，第一个要搞清楚的是对象模型QOM（QEMU Object Model）。QEMU用QOM管理所有设备，CPU也不例外。对于CPU，你会碰到三个关键结构体：

CPUState：这是CPU的通用状态，跟具体架构无关。它包含了CPU编号、线程ID、运行状态、异常标志、TLB等。所有架构的CPUState都长同一个样子或非常类似，相当于QEMU对“一颗CPU”的抽象。

CPUClass：这是CPU的“类”，通过它定义各种操作函数指针，比如reset（复位）、realize（实例化完成后的初始化）、dump_state（打印寄存器状态）、get_pc/set_pc（读取/设置程序计数器）等。你想让QEMU知道你新加的CPU该怎么复位、怎么打印寄存器，就是往CPUClass里填这些函数。

CPUArchState：这是与架构强相关的“环境”结构体，通常叫CPUXXXState，里面放着这个架构的通用寄存器、状态寄存器、控制寄存器、异常状态等。在QEMU源码里，它一般以env（environment）的名字被访问。比如x86的CPUX86State里就有regs[16]寄存器数组和eip指令指针，ARM的CPUARMState里就有xregs[31]等。

三者关系：CPUState是“外壳”，通过env指针访问CPUArchState，CPUClass则是定义“行为”的函数表。你用QOM创建一个CPU对象时，QEMU会根据TypeInfo分配内存，把CPUState和CPUArchState都挂上去，然后通过class_init注册CPUClass里的函数指针。

1.3 从guest指令到host指令的完整路径

这条流水线是你做CPU建模最需要理解的主干：

1. 取指：QEMU从guest的PC（Program Counter）指向的内存地址读取指令字节。
2. 解码：根据指令编码格式，识别出这条指令的操作码、寄存器号、立即数等。
3. 翻译：调用translate.c中的翻译函数，把这条guest指令翻译成一条或多条TCG中间指令。
4. 中间代码生成：TCG中间指令是一种类似RISC的、架构无关的表示，比如tcg_gen_mov_i32（32位移动）、tcg_gen_add_i32（32位加法）。
5. host指令生成：TCG后端把这些中间指令转换成host原生指令，放到TB里。
6. 执行：QEMU跳转到TB中执行生成的原生指令。

你写CPU建模代码时，核心工作在“解码”和“翻译”。解码要处理指令格式的各种位域，翻译则要把每个指令的语义，用TCG中间指令或helper函数实现。后端的host指令生成，绝大部分情况下你不需要碰，TCG已经帮你处理了x86、ARM、RISCV等常见host架构。

1.4 建模前先想清楚：你是“功能模拟”还是“周期精确”

这是很多初学者容易忽略的问题。QEMU默认只保证“功能一致”，也就是guest程序运行结果一致，但不保证每条指令用了多少时钟周期。它追求的是运行速度和跨平台能力。

如果你的目标是跑操作系统、做软件调试、验证指令集功能，那么功能模拟完全够用。

如果你要做硬件时序验证、流水线冲突分析、精确Cache miss次数统计，QEMU默认模型帮不上忙。你需要自己扩展或者考虑其他工具。这个决策会影响你后续写helper函数和TCG翻译时的粒度——功能模拟可以直接用helper做复杂操作，周期精确则要把每个微操作拆得很碎，性能会大打折扣。

2. CPU建模的代码结构与添加新架构的完整流程

2.1 先看现有架构是怎么组织的

在QEMU源码中，每个架构在target/目录下占一个文件夹，例如target/arm/、target/riscv/、target/i386/。每个目录里的文件各有分工，但结构高度相似：

• cpu.h：定义CPUArchState、CPU类、寄存器访问宏。
• cpu.c：定义CPUClass、QOM TypeInfo、reset和realize函数。
• translate.c：解码和翻译的核心，把guest指令变成TCG IR。
• helper.c：实现需要调用的C函数，比如复杂的地址转换、内部函数、系统寄存器访问。
• helper.h：声明helper函数，QEMU用这个头文件自动生成调用桩代码。
• meson.build：构建脚本，告诉QEMU编译哪些文件。

如果你是第一次上手，最省力的办法是拿一个结构比较简洁的架构来对照。我个人推荐看target/riscv，它比较清晰，指令数量也不算多。target/arm虽然功能全，但代码量大、历史包袱多，不太适合新手直接抄作业。

2.2 定义你的CPU类型和状态结构

新建架构文件夹后，第一步先在cpu.h里定义你的CPU状态。

typedef struct CPUMyArchState { uint32_t regs[16]; // 通用寄存器 uint32_t pc; // 程序计数器 uint32_t status; // 状态寄存器 // ... 其他架构相关的寄存器 } CPUMyArchState; struct MyArchCPU { CPUState parent_obj; CPUMyArchState env; // 其他实例相关字段 }; #define TYPE_MYARCH_CPU "myarch-cpu" #define MYARCH_CPU(obj) OBJECT_CHECK(MyArchCPU, (obj), TYPE_MYARCH_CPU)

紧接着在cpu.c里注册QOM类型：

static void myarch_cpu_class_init(ObjectClass *oc, void *data) { CPUClass *cc = CPU_CLASS(oc); DeviceClass *dc = DEVICE_CLASS(oc); cc->reset = myarch_cpu_reset; cc->realize = myarch_cpu_realize; cc->get_pc = myarch_cpu_get_pc; cc->set_pc = myarch_cpu_set_pc; cc->dump_state = myarch_cpu_dump_state; // ... } static const TypeInfo myarch_cpu_type_info = { .name = TYPE_MYARCH_CPU, .parent = TYPE_CPU, .instance_size = sizeof(MyArchCPU), .instance_init = myarch_cpu_init, .class_init = myarch_cpu_class_init, }; static void myarch_cpu_register_types(void) { type_register_static(&myarch_cpu_type_info); } type_init(myarch_cpu_register_types)

上面的type_init宏会在QEMU初始化时自动调用注册函数。这里有个容易被忽略的点：reset函数里一定要把CPUArchState里的寄存器和PC设成正确的默认值，不然后续启动时PC是0，大概率直接segfault或者从头取到无效指令。我建议在reset里至少做到：

static void myarch_cpu_reset(DeviceState *dev) { MyArchCPU *cpu = MYARCH_CPU(dev); CPUMyArchState *env = &cpu->env; env->pc = 0x1000; // 默认起始地址，具体取决于你的存储映射 memset(env->regs, 0, sizeof(env->regs)); env->status = 0; // 其他寄存器的默认值 }

注意，起始地址别硬编码成0，很多嵌入式SoC的复位向量在Flash或SRAM区域，你需要结合目标板的存储映射设置。

2.3 译码器与翻译器的实现要点

假设你已经根据指令集手册，把指令的编码格式整理得比较清楚了。翻译函数一般长这个模样：

static bool trans_myarch_add(DisasContext *ctx, arg_add *a) { TCGv t0 = tcg_temp_new(); TCGv t1 = tcg_temp_new(); tcg_gen_mov_tl(t0, cpu_reg[a->rd]); tcg_gen_add_tl(t1, cpu_reg[a->rs1], cpu_reg[a->rs2]); tcg_gen_mov_tl(cpu_reg[a->rd], t1); tcg_temp_free(t0); tcg_temp_free(t1); return true; }

这段代码的意思是：取源寄存器rs1和rs2的值相加，存回目标寄存器rd。cpu_reg[]这个数组需要你自己在翻译器初始化时把它和CPUMyArchState->regs[]的地址绑定。

每个架构的翻译函数译码方式不同。RISCV风格的架构，通常用decode_insn16、decode_insn32这类函数按操作码位域分发。如果你的指令集比较规整，可以直接写一个switch：

static void disas_myarch_insn(DisasContext *ctx, uint32_t insn) { uint8_t opcode = extract32(insn, 26, 6); // 假设高6位是opcode switch (opcode) { case 0x00: trans_myarch_add(ctx, insn); break; case 0x01: trans_myarch_sub(ctx, insn); break; // ... default: gen_invalid(ctx); break; } }

DisasContext是翻译阶段贯穿始终的上下文结构体，里面会记录当前PC、翻译状态、是否遇到分支、是否需要退出TB等。这个结构体通常也叫ctx，名字起得有点随意但大家都能理解。

翻译阶段必须关心的一个关键问题是：每次翻译完一条指令后要把ctx->base.pc_next更新到下一条指令的地址。QEMU用ctx->base.pc_next来决定当前TB是否继续翻译下一条guest指令。如果忘了更新，会导致所有指令翻译出来都跳到同一个地址，程序直接跑飞，而且这种bug特别难排查。

2.4 helper函数：什么时候该用C代码

TCG中间指令能做的操作是有限的——寄存器加减、访存、逻辑运算、跳转，这些可以。但有一类操作不适合用TCG指令硬拼，比如：

• 复杂的系统寄存器读写
• 地址翻译和MMU操作
• 需要访问QEMU内部对象的操作
• 乘法除法等相对重量级的运算（也可以按需拆分）

这种情况下，你需要在helper.c里写一个真正的C函数，然后在翻译器里通过gen_helper_xxx调用。以指令MUL Rd, Rs1, Rs2为例：

在helper.h里声明：

DEF_HELPER_3(myarch_mul, i32, i32, i32, i32)

在helper.c里实现：

uint32_t helper_myarch_mul(uint32_t a, uint32_t b) { return a * b; }

在翻译器里调用：

gen_helper_myarch_mul(cpu_reg[rd], cpu_reg[rs1], cpu_reg[rs2]);

为什么乘法要写成helper？一方面是因为TCG本身虽然有多字节乘法操作，但很多host后端没有直接的乘法指令，TCG会把它们拆成多个host指令，性能反而差；另一方面，乘法语义在guest里可能有溢出标志、饱和行为等副作用，用C代码表达更清晰。经验之谈：简单线性操作能内联就内联，复杂语义操作就走helper。helper越少，生成的代码质量越高，翻译块也越紧凑。

2.5 接入顶层模拟器：从target到machine

CPU模型写好了，还要把“一颗CPU”放进一个“板子”里跑起来。这一步对应QEMU里的hw/myarch/目录，常见的文件有myarch_machine.c。在这类文件里你会实现一个MachineState的初始化函数，创建CPU核心、内存、中断控制器等。

static void myarch_machine_init(MachineState *machine) { MyArchCPU *cpu; DeviceState *dev; int i; for (i = 0; i < machine->smp.cpus; i++) { cpu = MYARCH_CPU(object_new(TYPE_MYARCH_CPU)); object_property_set_int(OBJECT(cpu), "num-cpu", i, &error_fatal); qdev_realize(DEVICE(cpu), NULL, &error_fatal); // 创建地址空间、加载固件等 } // ... }

完成之后，在meson.build里把它加进构建系统，然后执行./configure --target-list=myarch-softmmu，再编译。如果能顺利生成qemu-system-myarch，你就能用：

qemu-system-myarch -machine myarch_virt -kernel firmware.bin

启动你的模拟器了。

3. 实操过程：从零添加一套极简指令集（以自定义架构为例）

3.1 定义指令集与编码格式

为了讲得具体一点，我们假设要为一个名叫“MyArch”的极简RISC架构建模，这个架构有：

• 16个32位通用寄存器r0-r15
• 一条32位PC
• 指令长度固定32位
• 指令格式：高6位是opcode，低26位是操作数

我们只需要支持5条指令：

这个指令集甚至都不需要编码字节对齐，我们直接用位域提取。这样做的好处是：让你先跑通整条QEMU流水线，再回头处理复杂的编解码。

3.2 从文件骨架到翻译函数，完整代码实现

先创建target/myarch/cpu.h，把状态结构和寄存器数组搞定：

#ifndef QEMU_MYARCH_CPU_H #define QEMU_MYARCH_CPU_H #include "qom/object.h" #include "cpu.h" #define TYPE_MYARCH_CPU "myarch-cpu" typedef struct CPUMyArchState { uint32_t regs[16]; uint32_t pc; uint32_t status; } CPUMyArchState; struct MyArchCPU { CPUState parent_obj; CPUMyArchState env; }; #endif

然后是target/myarch/cpu.c。关键是实现reset和realize，以及注册TypeInfo。翻译器在初始化时要拿到cpu_reg的地址，通常会用cpu_env作为基址，然后计算偏移量。这里有个取巧的做法：直接用offsetof(CPUMyArchState, regs)来做TCG的全局变量绑定。

接着是target/myarch/translate.c，这是最核心的部分。先定义寄存器TCG变量：

static TCGv cpu_reg[16]; static TCGv cpu_pc; static TCGv cpu_env; static const char *reg_names[16] = { "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15" }; static void myarch_translate_init(void) { int i; cpu_env = tcg_global_reg_new_ptr(TCG_AREG0, "env"); for (i = 0; i < 16; i++) { cpu_reg[i] = tcg_global_mem_new_i32(cpu_env, offsetof(CPUMyArchState, regs[i]), reg_names[i]); } cpu_pc = tcg_global_mem_new_i32(cpu_env, offsetof(CPUMyArchState, pc), "pc"); }

上面这个tcg_global_mem_new_i32就是告诉TCG：cpu_reg[i]绑定的内存地址是cpu_env + 寄存器偏移。cpu_env本身被硬编码到了TCG的全局寄存器TCG_AREG0中，翻译生成的host代码里会直接用这个寄存器保存CPUArchState的基址。

接下来是trans_myarch_add的翻译函数。我们已经看过代码，这里重点说一个细节：在翻译指令前，要把ctx->base.pc_next更新成当前指令的PC；翻译完后，再更新成下一条指令的PC。可以这样写：

static bool trans_myarch_add(DisasContext *ctx, arg_myarch_add *a) { TCGv t0 = tcg_temp_new(); tcg_gen_add_i32(t0, cpu_reg[a->rs1], cpu_reg[a->rs2]); tcg_gen_mov_i32(cpu_reg[a->rd], t0); tcg_temp_free(t0); return true; }

arg_myarch_add是一个存放解码结果的结构体，里面包含rd、rs1、rs2的位域值。严格来说需要从指令里提取：

static bool decode_insn(DisasContext *ctx, uint32_t insn) { arg_myarch_add add; uint8_t opcode = extract32(insn, 26, 6); switch (opcode) { case 0x00: // ADD add.rd = extract32(insn, 21, 5); add.rs1 = extract32(insn, 16, 5); add.rs2 = extract32(insn, 11, 5); return trans_myarch_add(ctx, &add); case 0x01: // SUB // ... case 0x02: // LW // ... case 0x03: // SW // ... case 0x04: // BEQ // ... default: gen_invalid(ctx); return true; } }

访存指令LW的实现需要用到TCG的访存接口：

static bool trans_myarch_lw(DisasContext *ctx, arg_myarch_lw *a) { TCGv t0 = tcg_temp_new(); TCGv t1 = tcg_temp_new(); // t1 = Rs1 + offset tcg_gen_mov_i32(t1, cpu_reg[a->rs1]); tcg_gen_addi_i32(t1, t1, a->offset); // t0 = load(t1) tcg_gen_qemu_ld32u(t0, t1, ctx->mem_index); tcg_gen_mov_i32(cpu_reg[a->rd], t0); tcg_temp_free(t0); tcg_temp_free(t1); return true; }

这里的ctx->mem_index是QEMU内存访问的索引参数，用来区分指令取指、数据读、数据写等不同的TLB上下文。通常用DEF_TLB_MMIO或者自定义的get_mem_index(ctx)获取。访存类型（32位、16位、8位，是否带符号）也要和guest指令语义严格对应，不然内存数据会错位。

分支指令BEQ是另一个容易出问题的点。翻译分支时，你要用gen_brcond生成条件分支，再用gen_set_label设置目标标签：

static bool trans_myarch_beq(DisasContext *ctx, arg_myarch_beq *a) { TCGv t0 = tcg_temp_new(); TCGv t1 = tcg_temp_new(); TCGv target = tcg_temp_new(); TCGLabel *l_true = gen_new_label(); TCGLabel *l_done = gen_new_label(); tcg_gen_mov_i32(t0, cpu_reg[a->rs1]); tcg_gen_mov_i32(t1, cpu_reg[a->rs2]); tcg_gen_brcond_i32(TCG_COND_EQ, t0, t1, l_true); // 不相等的情况，继续下一条 tcg_gen_mov_i32(cpu_pc, tcg_constant_i32(ctx->base.pc_next)); tcg_gen_br(l_done); // 相等的情况，跳转到 offset gen_set_label(l_true); tcg_gen_mov_i32(cpu_pc, tcg_constant_i32(ctx->base.pc + a->offset)); gen_set_label(l_done); tcg_temp_free(t0); tcg_temp_free(t1); tcg_temp_free(target); return true; }

这段代码里有个很容易忽略的点：分支指令翻译时，如果条件成立要和PC偏移一起算好，并且要把PC的更新放在分支发生前。TCG是基本块翻译器，guest的一条分支指令翻译后可能生成多个host基本块，但翻译器必须确保PC的设置逻辑和guest语义完全一致。

3.3 搞定生成器入口：gen_intermediate_code

QEMU翻译一个TB时，会调用gen_intermediate_code(CPUState *cs, TranslationBlock *tb, int max_insns)，这个函数你需要在translate.c里实现。它的大致结构是：

void gen_intermediate_code(CPUState *cs, TranslationBlock *tb, int *max_insns) { DisasContext ctx; uint32_t insn; target_ulong pc_start = tb->pc; int num_insns = 0; ctx.base.pc_next = pc_start; ctx.base.tb = tb; ctx.pc = pc_start; ctx.mem_index = 0; gen_tb_start(tb); while (num_insns < max_insns && !ctx.base.is_jmp) { ctx.pc = ctx.base.pc_next; insn = cpu_ldl_code(cs, ctx.base.pc_next); ctx.base.pc_next += 4; decode_insn(&ctx, insn); num_insns++; // 如果指令可能导致PC不确定，跳转，或者TB满了，就停止 if (ctx.base.is_jmp || num_insns >= MAX_INSNS_PER_TB) { break; } } // 如果没遇到跳转，强制把PC更新到当前值并退出TB if (!ctx.base.is_jmp) { tcg_gen_mov_i32(cpu_pc, tcg_constant_i32(ctx.base.pc_next)); tcg_gen_exit_tb(NULL, 0); } gen_tb_end(tb); }

这个函数是QEMU CPU建模里每个新架构都必须实现的。具体写法可以参照target/riscv/translate.c的riscv_tr_translate_insn和riscv_tr_tb_stop。总的原则是：保证每次退出TB时PC一定被更新成了正确的下一条指令地址。

3.4 在machine层创建CPU并加载固件

hw/myarch/myarch_machine.c里的核心工作是初始化CPU和内存。一个最简单的model：

static void myarch_virt_init(MachineState *machine) { MyArchCPU *cpu; MemoryRegion *ram; // 创建CPU cpu = MYARCH_CPU(object_new(TYPE_MYARCH_CPU)); qdev_realize(DEVICE(cpu), NULL, &error_fatal); // 创建内存 ram = g_new(MemoryRegion, 1); memory_region_init_ram(ram, NULL, "myarch.ram", machine->ram_size, &error_fatal); memory_region_add_subregion(get_system_memory(), 0x0, ram); // 加载固件到内存起始位置 if (machine->kernel_filename) { load_image_targphys(machine->kernel_filename, 0x0, machine->ram_size, NULL); } }

注意，这里我假设guest复位后PC指向0x0，所以固件加载到地址0x0。实际项目中，加载地址要与reset函数里的PC一致，否则CPU永远跑不到你的固件代码上。接入meson.build时，在target/myarch/meson.build里写：

myarch_ss = ss.source_set() myarch_ss.add(files( 'cpu.c', 'translate.c', 'helper.c', 'machine.c' )) target_arch += {'myarch': myarch_ss}

然后回到QEMU根目录执行./configure --target-list=myarch-softmmu && make。如果一切顺利，你会得到build/qemu-system-myarch。这一套流程走通，你的第一个CPU模型就算“能跑”了。

4. 常见问题排查与调试技巧实录

4.1 启动就segfault，先查PC和TLB

新架构的CPU模型最常见的崩溃场景是“点启动就崩”。排查顺序我给一个固定的套路：

1. 确认guest入口PC是否正确。在reset里打印addr，看PC是不是你要的固件加载地址。
2. 确认内存映射是否正确。固件加载的地址有没有真的映射到系统内存。
3. 确认TLB和内存访问函数是否实现。如果你在translate的访存指令里用了ctx->mem_index，但machine里没有设置对应的TLB，大概率会触发abort。
4. 确认CPUClass的realize是否正确调用了。一旦realize没执行，CPUState内部很多字段没初始化，后续任何操作都可能崩。

用日志定位的方式：

qemu-system-myarch -d in_asm,cpu -D qemu.log -kernel firmware.bin

in_asm会打印翻译出来的guest指令，cpu会打印每个TB执行时的CPU寄存器状态。打开这个日志，能直观看到PC走到哪里、寄存器变成什么样。如果第一条翻译指令就不是固件的第一条指令，说明reset或者取指地址有问题。

4.2 guest指令执行结果不对，先用“最小用例”缩小范围

执行指令结果错乱，最常见的几个原因：

• 解码时位域提取错误。extract32的起始位和宽度写错了。
• 翻译时操作数顺序写反。比如把rs1和rs2搞反，或者目标寄存器写错。
• 访存宽度或符号扩展不对。ld32u和ld32s的区别没注意。
• PC更新逻辑有漏洞。条件分支不更新PC，或者无条件跳转没设置PC。

我一般会在qemu.log里对比一条指令翻译前后的寄存器状态，再拿一个已知结果的最小汇编程序去跑。例如：

add r1, r0, r2

让r0=1、r2=2，期望r1=3。如果执行后r1的值不对，再用单步调试去查TCG IR。

4.3 用GDB调试QEMU自身：断点打在helper上

有时候guest层面的日志看不出问题，就需要直接调试QEMU进程。最直接的方法是：

gdb --args qemu-system-myarch -kernel firmware.bin

然后在helper函数、gen_intermediate_code、myarch_cpu_reset等关键函数上打断点。比如怀疑helper_myarch_mul算错了，就break helper_myarch_mul，运行后查看参数和返回值。

如果你想调试guest程序本身，用QEMU的gdbstub更合适。启动QEMU时加-s -S参数，-S表示启动时暂停CPU，-s表示在tcp:1234端口开放gdbstub，然后用宿主机的gdb连接：

gdb target remote :1234 b *0x0 continue

这样可以直接在guest指令地址上下断点，非常适合验证CPU模型的指令执行顺序和寄存器变化。

4.4 排查表：新CPU建模的典型问题速查

5. 性能优化与进阶扩展

5.1 减少helper调用：能内联就内联

新CPU建模的速度瓶颈，绝大多数情况下不在TCG后端，而在你的翻译层写了太多helper调用。每个helper调用背后是一次C函数调用，会打断host指令流水线，还可能导致寄存器溢出到栈上。

举个例子，如果你有一条AND指令，应该直接用TCG的tcg_gen_and_i32，而不是写一个helper_myarch_and。加法、减法、移位、逻辑运算这类简单操作，TCG本身就有对应的中间指令，翻译后直接映射到host指令，非常快。

只有在涉及语义复杂、需要访问QEMU内部状态（异常、中断、MMU）时才用helper。

5.2 利用直接块链接提升分支性能

QEMU的TB之间，默认是通过一个tcg_gen_exit_tb退出，再回到QEMU主循环查找下一个TB。如果每次跳转都走这个流程，开销很大。QEMU提供了“直接块链接”（direct block chaining）机制，让一个TB的末尾直接跳转到另一个TB的host代码地址，省掉中间查找过程。

在翻译分支指令时，尽量使用tcg_gen_goto_tb和tcg_gen_exit_tb配合。以无条件跳转为例：

tcg_gen_goto_tb(0); tcg_gen_mov_i32(cpu_pc, tcg_constant_i32(target)); tcg_gen_exit_tb(tb, 0);

goto_tb会预留host端的跳转位置，exit_tb告诉QEMU这个TB结束后跳到哪个地址。后续再次执行到这条分支时，QEMU会直接patch这段host代码，把跳转目标改成已经翻译好的目标TB地址，省去下一次查找。这个机制对循环密集的guest程序提升非常明显。

5.3 调大TB容量，提升翻译缓存命中率

QEMU默认每个TB最多翻译max_insns条guest指令，通常是CF_COUNT_MASK或编译时确定的阈值。如果你的guest代码里有很多短小的基本块，可以把每个TB的最大指令数调大，提高缓存命中率，减少TB查找和翻译次数。

在gen_intermediate_code里，我习惯把max_insns写到512左右（默认通常是32到64），对纯计算型负载性能提升显著。但要注意，TB过大可能导致翻译时间变长，而且某些需要精确异常处理的场景会影响精度。需要结合你的场景做benchmark再调。

5.4 多线程与icount：取决于你的目标

QEMU支持多线程TCG（MTTCG），也就是说在有多个vCPU的guest里，多个TCG线程可以并行执行多个CPU核心的翻译块。如果你的目标是模拟一个SMP系统，需要在machine创建CPU时设置CPUState->nr_threads等相关属性。

但多线程也带来一个麻烦：helper函数如果访问了共享的QEMU状态，需要加锁或者用原子操作，否则会在并发环境下产生数据竞争。我的建议是第一步先做单核模型，功能验证通过后，再考虑MTTCG。否则你会在“资源竞争”和“guest指令语义错误”之间来回横跳，很难定位问题。

如果你还要做“按指令计数”的模拟（比如精确模拟guest执行了多少条指令），就要开启-icount模式。这个模式会显著影响TCG的翻译策略，性能和精度需要权衡。对大多数功能模拟场景，我建议先不开。

5.5 模块化设计：用decodetree生成解码器

当指令数量增多后，手写switch-case的解码器会越来越难维护。QEMU提供了一个叫decodetree的DSL工具，可以用类似正则的语法描述指令编码模式，自动生成解码函数，把分散的位域提取和指令分发逻辑集中管理。

例如在target/myarch/insn.decode里写：

add 000000 ..... ..... ..... 00000 00000 sub 000001 ..... ..... ..... 00000 00000 lw 000010 ..... ..... ................

然后由decodetree脚本生成C代码，直接接到decode_insn里。这种写法的好处：指令模式一目了然、减少手写位域提取的错误、新增指令只需要加一行描述。

如果你的架构指令编码比较复杂，建议尽早把指令集手册里的编码表整理成decodetree格式，而不是靠手写几十个switch分支。

6. 从功能验证到复杂场景的进阶路径

6.1 加中断和异常：CPU建模的真正难点

当你把基础指令流跑通后，下一步通常是要支持中断、异常、陷入（trap）。这一步会把你的CPU模型从“玩具”推向“可用的模拟器”。

在QEMU里，中断和异常的机制是：

• CPUClass里定义tcg_ops和cpu_exec_interrupt等函数。
• CPUArchState里要有中断挂起标志、异常向量基址、异常状态寄存器。
• translate.c里要有检测中断、异常跳转的逻辑。
• helper函数或TCG翻译中，遇到访存异常、非法指令、特权级切换时，调用raise_exception设置异常状态。

以最简单的异常处理为例，当guest执行到非法指令时，你需要在翻译器里：

static void gen_exception(DisasContext *ctx, int excp) { TCGv_i32 tmp = tcg_constant_i32(excp); gen_helper_raise_exception(cpu_env, tmp); ctx->base.is_jmp = DISAS_NORETURN; }

然后在helper.c里实现helper_raise_exception，它负责设置CPUArchState的异常状态、更新PC到异常向量、触发CPUState->exception_index，让QEMU主循环进入异常处理流程。

这一步是整个CPU建模里最需要熟悉QEMU内部机制的环节。我建议多参考target/arm/helper.c和target/riscv/cpu_helper.c里对异常和中断的处理方式，它们对各种复杂场景（嵌套异常、返回地址、异常优先级）都有成熟实现。

6.2 跑一个最小RTOS：验证模型的完整度

当你的CPU模型支持基本中断和异常后，一个非常重要的里程碑是：“让一个RTOS在这个模拟CPU上正常运行”。

拿FreeRTOS举例，你只需要在板级支持文件里实现：

• 系统时钟中断（定时器中断）
• 上下文切换（通常是PendSV或软件中断）
• 内存管理（如果有MMU/MPU功能）

如果你的CPU模型跑起了FreeRTOS，并且任务切换、信号量、队列都正常，说明你的模型已经覆盖了大部分CPU核心功能。这时候再回头优化性能和增加复杂特性（MMU、缓存、多核），心里就有底了。

6.3 给QEMU上游提交新架构补丁时的几个建议

如果你不满足于本地自用，想把新架构补丁提交给QEMU上游，有几点实用建议：

第一，代码风格严格遵循QEMU的scripts/checkpatch.pl检查结果。QEMU对代码风格的挑剔程度在开源项目里是出了名的，缩进、空格、括号都有自己的规矩。提交前先跑一下检查脚本能省很多来回修改的功夫。

第二，重点写好meson.build和configure的集成，保证新架构在--target-list=myarch-softmmu和--target-list=myarch-linux-user两种模式下都能编译。如果是纯软核，可能还需要附带linux-user支持，这会让你的架构能被拿来直接跑Linux用户态程序。

第三，提供完整的文档。QEMU上游要求新架构有docs/system/target-myarch.rst之类的文档，说明架构特性、启动方式、编程接口。很多开发者忽略这块，但上游维护者特别看重。

第四，维护好自己的测试用例。QEMU的tests/tcg/myarch/目录下，需要提供一批guest测试程序，确保你的架构在持续集成中不会退化。没有测试的架构补丁，基本不可能被合入主线。

7. 最后再分享一点我的个人体会

从我做过几个模拟器CPU模型的经验来看，QEMU的CPU建模最忌讳一上来就贪大求全。如果你一开始就想着把所有特权指令、浮点、SIMD、MMU全部实现，很容易陷在细节里几个月出不来。正确路径永远是先跑通最小指令集，再逐步加功能。

我每次给一个新架构起步时，都是先拿C语言写一个最小的解释器原型，把指令语义验证清楚，再搬到QEMU的translate.c里。这样可以把“指令语义错误”和“QEMU机制错误”隔离开，排查起来快很多。实际动手时，多看看target/riscv和target/arm的代码，把它们的框架理解透，再动手写自己的架构，这会比从零硬写省很多时间。希望这些实操经验能帮你在QEMU里把自己的CPU跑起来。