解决QEMU无法从非0x80000000处开始执行

1 背景介绍

在使用NEMU与QEMU做DiffTest的场景下，运行的固件为《RISC-V体系结构编程与实践》中示例代码chapter_2，编译出来的固件二进制文件为：benos_payload.bin。

将benos_payload.bin，放置在NEMU中内存0x80000000处，NEMU通过Socket发送放置到QEMU中内存0x31e00000处。

计划让QEMU直接从0x31e00000开始执行，而不是常规的0x80000000。

对NEMU源码，做了如下修改。将nemu/src/cpu/difftest/dut.c文件，init_difftest函数，修改为如下：

void init_difftest(char *ref_so_file, long img_size, int port) {...ref_difftest_init(port);// 将benos_payload.bin发送到QEMU的0x31e00000内存处ref_difftest_memcpy(0x31e00000, guest_to_host(RESET_VECTOR), img_size, DIFFTEST_TO_REF);// pc寄存器设置为0x31e00000cpu.pc = 0x31e00000;// 将NEMU的x0 ~ x31和pc寄存器值，发送到QEMU中，覆盖QEMU原有寄存器ref_difftest_regcpy(&cpu, DIFFTEST_TO_REF);// 让QEMU执行3000条指令ref_difftest_exec(3000);
}

只要NEMU执行了上述代码，那么QEMU的0x31e00000处保存的就是benos_payload.bin，并且pc寄存器值为0x31e00000，当执行ref_difftest_exec函数时，预期QEMU就可以从0x31e00000开始执行。

2 问题描述

QEMU无法从0x31e00000开始执行，甚至一条指令都取不出来（qemu-7.1.0/target/riscv/translate.c中decode_opc函数第1052行，不会中断停下来）。

3 原因分析

我们调试QEMU源码，发现NEMU通过Socket发给QEMU的二进制镜像，并没有被写入QEMU的0x31e00000内存中，而是跳过了。
这点找一个正常向0x80000000写入成功的例子，来对照一下，就很容易定位。
因此，内存中没有该二进制可执行内容，故无法取指执行。

4 解决办法

在qemu-7.1.0/hw/riscv/spike.c文件，spike_board_init函数中，有如下调用：

/* register system main memory (actual RAM) */
memory_region_add_subregion(system_memory, memmap[SPIKE_DRAM].base, machine->ram);

注册系统主内存时，默认使用spike.c文件中spike_memmap数组，第SPIKE_DRAM个元素，该数组定义如下：

static const MemMapEntry spike_memmap[] = {[SPIKE_MROM] =     {     0x1000,     0xf000 },[SPIKE_HTIF] =     {  0x1000000,     0x1000 },[SPIKE_CLINT] =    {  0x2000000,    0x10000 },[SPIKE_DRAM] =     { 0x80000000,        0x0 },
};

因此，QEMU只认为0x80000000开始为DRAM，其他不认。
我们只需要，将0x80000000修改为0x30000000，再次尝试从0x31e00000运行，就成功了。

5 踩坑回忆

5.1 坑1 - 怀疑设备树有问题

当时第一反应，是以为设备树不对，因此修改了设备树中memory地址定义。事实证明没用。

后面看了QEMU的spike_board_init函数代码，其实QEMU会默认创建一个设备树，该设备树中memory地址，默认使用的是spike_memmap数组，因此我们只要改了spike_memmap数组，那设备树中memory地址也会改变。

以下，附一些设备树的常用命令。

从QEMU中导出设备树，启动QEMU时，添加如下选项：

-M virt,dumpdtb=123.dtb 

将DTS编译为DTB：

dtc -I dts -O dtb -o 123.dtb 123.dts

将DTB转为DTS：

dtc -I dtb -O dts 123.dtb -o 123.dts

5.2 坑2 - 怀疑QEMU中内存未写入成功

真实原因就是这个。
其实在qemu-7.1.0/gdbstub.c中有一对函数：

• handle_write_mem函数
• handle_read_mem函数

NEMU发送数据给QEMU时，会调用handle_write_mem，如果在NEMU中再实现一个读内存的发包函数，那么就可以从QEMU中读取内存，在NEMU中将读到的数据与之前写入的数据，进行比较，很容易定位，两次数据不一致，内存写入有问题。

附，写内存数据包格式：

// 写入内存，数据包
"M0x31e00000,5dc:1711000013010100b7120000330151006f00001e1301..."

• M表示写入内存，m表示读取内存。
• 0x31e00000：表示写入内存的地址为0x31e00000。
• 0x5dc：表示后面跟的，数据长度为1500字节，实际数据包中因为是2个字符表示一个字节，因此后面实际字符串数据长度为1500*2。
• 1711000013010…：表示数据，"171100"解析后，就是0x17 0x11 0x00，低字节在前，高字节在后。

5.3 QEMU地址空间分析过程

以下内容很乱，请忽略，纯记录。

QEMU中有一个结构GDBState，包含了很多信息，就包含CPU的地址空间。
该结构中有个成员g_cpu，层次关系如下：

// 是否为DRAM地址
g_cpu->cpu_ases[0].as->current_map->dispatch->mru_section->mr->ram
// DRAM基址
g_cpu->cpu_ases[0].as->current_map->dispatch->mru_section->offset_within_address_space
// DRAM空间大小
g_cpu->cpu_ases[0].as->current_map->dispatch->mru_section->size

MemoryRegionSection表示一个地址范围，如[0x80000000, 0x88000000]。
其offset_within_address_space表示基址，size表示大小。

typedef QTAILQ_HEAD(CPUTailQ, CPUState) CPUTailQ;
// 展开后为：
typedef union CPUTailQ {struct CPUState* tqh_first;    // first elementQTailQLink tqh_circ;       // last element
} CPUTailQ;extern CPUTailQ cpus;
CPUState* cpu = first_cpu = (&cpus)->tqh_first

打的一些断点：

• b gdbstub.c:836，gdbstub.c中gdb_first_attached_cpu()
• b cpus-common.c:92