QEMU on 夜云泊

QEMU Decodetree详解

Sat, 10 Aug 2024 21:08:03 +0000

QEMU 在 decode 指令的时候，需要调用各平台所定义的 instruction decoders 来解析指令。如在 ARM 平台下，就定义了：disas_arm_insn()、disas_thumb_insn() 及 disas_thumb2_insn() 等来分别负责 ARM 32-bits 指令、ARM Thumb 指令及 ARM Thumb2 指令的解析。

而 Decodetree 则是由 Bastian Koppelmann 于 2017 年在移植 RISC-V QEMU 的时候所提出来的机制 (详见：讨论邮件1、讨论邮件2)。提出该机制主要是因为过往的 instruction decoders (如：ARM) 都是采用一堆 switch-case 来做判断。不仅难阅读，也难以维护。

因此 Bastian Koppelmann 就提出了 Decodetree 的机制，开发者只需要通过 Decodetree 的语法定义各个指令的格式，便可交由 Decodetree 来动态生成对应包含 switch-case 的 instruction decoder .c 文档。

Decodetree 特别适合像 RISC-V 这种具有固定指令格式的 ISA。

因为各字段都在固定的位置，(如 RISC-V 的 opcode 都是固定在 bits[6..0] 的位置)。

Responsive Image

Decodetree 其实是由 Python script (./scripts/decodetree.py) 所生成的。使用文档可以参考：./docs/devel/decodetree.rst，里面有详细定义了其语法的格式。QEMU 在编译时，会调用 Decodetree，根据各平台所定义的 decode 文档，动态生成对应的 decoder。

如 RISC-V 的 instruction decoders 就是被定义在：./target/riscv/*.decode 中。其 Makefile.obj 就有如下的声明：

...

DECODETREE = $(SRC_PATH)/scripts/decodetree.py

decode32-y = $(SRC_PATH)/target/riscv/insn32.decode
decode32-$(TARGET_RISCV64) += $(SRC_PATH)/target/riscv/insn32-64.decode

...

target/riscv/decode_insn32.inc.c: $(decode32-y) $(DECODETREE)
	$(call quiet-command, \
	  $(PYTHON) $(DECODETREE) -o $@ --static-decode decode_insn32 \
          $(decode32-y), "GEN", $(TARGET_DIR)$@)

Decodetree 的语法共分为：Fields、Argument Sets、Formats、Patterns 五部分。本文将介绍如何通过 Decodetree 的语法，来动态生成一个指令的 decoder。

Field

Field 定义如何取出一指令中，各字段 (eg: rd, rs1, rs2, imm) 的值。

field_def     := '%' identifier ( unnamed_field )* ( !function=identifier )?
unnamed_field := number ':' ( 's' ) number

其语法由 % 开头，随后紧接着一个 identifier 及零个或多个 unamed_field，并可再加上可选的 !function。

identifier 可由开发者自定，如：rd、imm… 等。
unamed_field 定义了该字段的所在比特。第一个数字定义了该字段的 least-significant bit position，第二个数字则定义了该字段的比特长度。另外可加上可选的 s 字符来标明在取出该字段后，是否需要做符号扩展。
- Eg：%rd 7:5 代表 rd 占了指令中 bits 7 ~ bits 11 的位置 (insn[11:7])，共 5 bits。
!function 定义在截取出该字段的值后，所会再调用的 function。

Field (32-bits 指令) 最后会生成对应的 extract32() 及 sextract32() 代码，以用来取得指令中各字段的值：

Field 示例

Input	Generated code
%disp 0:s16	sextract(i, 0, 16)
%imm9 16:6 10:3	extract(i, 16, 6) « 3
%disp12 0:s1 1:1 2:10	sextract(i, 0, 1) « 11
%shimm8 5:s8 13:1 !function=expand_shimm8	expand_shimm8(sextract(i, 5, 8)) « 1

以 RISC-V 的 U-type 指令为例：

Responsive Image

其中，imm 占 insn[31:12]，共20位，rd 占 insn[11:7]，且 imm 需要做符号扩展后 左移 12 位 (20-bit immediate is shifted left by 12 bits to form U immediates)。因此，如果我们要定义 RISC-V 的 U-type 指令，则可以声明成：

%rd       7:5
%imm_u    12:s20                 !function=ex_shift_12

20 表示占 20 bits

最后会生成如下的代码：

static void decode_insn32_extract_u(DisasContext *ctx, arg_u *a, uint32_t insn)
{
    a->imm = ex_shift_12(ctx, sextract32(insn, 12, 20));
    a->rd = extract32(insn, 7, 5);
}

static void decode_insn32_extract_u() 是由下文 Format 定义所生成的，而 arg_u *a 则是由 Argument Set 定义所生成的，将会在后面的部分再做说明。

可以看到：

a->imm = ex_shift_12(ctx, sextract32(insn, 12, 20));
a->rd = extract32(insn, 7, 5);

a->imm 是由 insn[31:12] 所取得并做符号扩展，且会再调用 ex_shift_12() 来 左移 12 个 bits。

P.S. RISC-V 的 ex_shift_12() 是通过定义在./target/riscv/translate.c 中 EX_SH 这个 macro 所展开的：

#define EX_SH(amount) \
    static int ex_shift_##amount(DisasContext *ctx, int imm) \
    {                                         \
        return imm << amount;                 \
    }
EX_SH(1)
EX_SH(2)
EX_SH(3)
EX_SH(4)
EX_SH(12)

a->rd 是由 insn[11:7] 所取得。

此外，在 Decodetree 的 spec 中也有提到，我们可以通过只定义 !function 来直接调用该 function。在这种情况下，只有 DisasContext 会被传入该 function。

如 ARM Thumb ./target/arm/t16.decode 就有定义：

# Set S if the instruction is outside of an IT block.
%s               !function=t16_setflags

static void disas_t16_extract_addsub_2i(DisasContext *ctx, arg_s_rri_rot *a, uint16_t insn)
{
    a->imm = extract32(insn, 6, 3);
    a->rn = extract32(insn, 3, 3);
    a->rd = extract32(insn, 0, 3);
    a->s = t16_setflags(ctx); 
    a->rot = 0;
}

请注意，未包含任何 unnamed_fields 或 !function 的 Field 会被视为错误。

Argument Set

Argument Set 定义用来保存从指令中所截取出来各字段的值。

args_def    := '&' identifier ( args_elt )+ ( !extern )?
args_elt    := identifier

其语法由 & 开头，随后紧接着一个或多个的 identifier ，并可再加上可选的 !extern 。

identifier 可由开发者自订，如：regs、loadstore… 等。
!extern 则表示是否在其他地方已经由其他的 decoder 定义过。如果有该字段，就不会再次生成对应的 argument set struct。

Argument Set 示例

例1：

&ampreg3 ra rb rc

会生成以下的 argument set struct：

typedef struct {
    int ra;
    int rb;
    int rc;
} arg_reg3;

例2：

&loadstore reg base offset

则会生成以下的 argument set struct：

typedef struct {
    int base;
    int offset;
    int reg;
} arg_loadstore;

因此，以刚刚的 RISC-V U-type 指令为例，我们需要从指令中截取 imm 及 rd 字段的值，可以声明其 argument set 如下：

&u    imm rd

最后会生成以下的 argument set struct：

typedef struct {
    int imm;
    int rd;
} arg_u;

此 argument set struct 会被传入由 Format 定义所生成的 extract function：

static void decode_insn32_extract_u(DisasContext *ctx, arg_u *a, uint32_t insn)
{
    a->imm = ex_shift_12(ctx, sextract32(insn, 12, 20));
    a->rd = extract32(insn, 7, 5);
}

所传入的arg_u 会保存从指令中截取出的 imm 及 rd 字段的值，待后续使用。

Format

Format 定义了指令的格式 (如 RISC-V 中的 R、I、S、B、U、J-type)，并会生成对应的 decode function。

fmt_def      := '@' identifier ( fmt_elt )+
fmt_elt      := fixedbit_elt | field_elt | field_ref | args_ref
fixedbit_elt := [01.-]+
field_elt    := identifier ':' 's'? number
field_ref    := '%' identifier | identifier '=' '%' identifier
args_ref     := '&' identifier

其语法由 @ 开头，随后紧接着一个 identifier 及一个以上的 fmt_elt。

identifier 可由开发者自订，如：opr、opi… 等。
fmt_elt 则可以采用以下不同的语法：
- fixedbit_elt 包含一个或多个 0、1、.、-，每一个代表指令中的 1 个 bit。
  - . 代表该 bit 可以用 0 或是 1 来表示。
  - - 代表该 bit 完全被忽略。
- field_elt 可以用 Field 的语法来声明。
  - Eg：ra:5、rb:5、lit:8
- field_ref 有下列两种格式 (以下范例参考上文所定义之 Field)：
  - '%' identifier：直接参考一个被定义过的 Field。
    - 如：%rd，会生成：
      a->rd = extract32(insn, 7, 5);
  - identifier '=' '%' identifier：直接参考一个被定义过的 Field，但通过第一个 identifier 来重命名其所对应的 argument 名称。此方式可以用来指定不同的 argument 名称来参考至同一个 Field。
    - 如：my_rd=%rd，会生成：
      a->my_rd = extract32(insn, 7, 5);
- args_ref 指定所传入 decode function 的 Argument Set。若没有指定 args_ref 的话，Decodetree 会根据 field_elt 或 field_ref 自动生成一个 Argument Set。此外，一个 Format 最多只能包含一个 args_ref。

当 fixedbit_elt 或 field_ref 被定义时，该 Foramt 的所有的 bits 都必须被定义 (可通过 fixedbit_elt 或 . 来定义各个 bits，空格会被忽略)。

Format 示例

@opi    ...... ra:5 lit:8    1 ....... rc:5

定义了 op1 这个 Format，其中：

insn[31:26] 可为 0 或 1。
insn[25:21] 为 ra。
insn[20:13] 为 lit。
insn[12] 固定为 1。
insn[11:5] 可为 0 或 1。
insn[4:0] 为 rc。

此 Format 会生成以下的 decode function：

typedef struct {
    int lit;
    int ra;
    int rc;
} arg_decode_insn320;

static void decode_insn32_extract_opi(DisasContext *ctx, arg_decode_insn320 *a, uint32_t insn)
{
    a->ra = extract32(insn, 21, 5);
    a->lit = extract32(insn, 13, 8);
    a->rc = extract32(insn, 0, 5);
}

由于我们没有指定 args_ref，因此 Decodetree 根据了 field_elt 的定义，自动生成了 arg_decode_insn320 这个 Argument Set。

以 RISC-V I-type 指令为例：

# Fields:
%rs1       15:5
%rd        7:5

# immediates:
%imm_i    20:s12

# Argment sets:
&i    imm rs1 rd

@i       ........ ........ ........ ........ &i      imm=%imm_i     %rs1 %rd

定义了 i 这个 Format，其中：

insn[31:20] 为 imm，且为符号扩展。
insn[19:5] 为 rs1。
insn[11:7] 为 rd。

此外，我们可以看到：

此 Format 指定了 Argument Set：&i。 &i 中必须包含所有有用到的 arguments (也就是：imm、rs1 及 rd)
imm 是通过重命名的方式来参考 %imm_i 这个 Field。

此范例会生成以下的 decode function：

typedef struct {
    int imm;
    int rd;
    int rs1;
} arg_i;


static void decode_insn32extract_i(DisasContext *ctx, arg_i *a, uint32_t insn)
{
    a->imm = sextract32(insn, 20, 12); 
    a->rs1 = extract32(insn, 15, 5);
    a->rd = extract32(insn, 7, 5);
}

相比于第一个范例，由于这次我们有指定 args_ref：&i，因此对应的 arg_i 会被传入 decode function。

回到先前的 RISC-V U-type 指令，我们可以如同 I-type 指令定义其格式：

# Fields:
%rd        7:5

# immediates:
%imm_u    12:s20                 !function=ex_shift_12

# Argument sets:
&u    imm rd

@u       ....................      ..... ....... &u      imm=%imm_u          %rd

定义了 u 这个 Format，其中：

insn[31:12] 为 imm，且为符号扩展。
insn[11:7] 为 rd。

会生成以下的 decode function：

typedef struct {
    int imm;
    int rd;
} arg_u;


static void decode_insn32_extract_u(DisasContext *ctx, arg_u *a, uint32_t insn)
{
    a->imm = ex_shift_12(ctx, sextract32(insn, 12, 20));
    a->rd = extract32(insn, 7, 5);
}

我们可以看到：

此 Format 指定了 Argument Set：&u。 &u 中必须包含所有有用到的 arguments (也就是：imm、rd)
imm 是通过重命名的方式来参考 %imm_u 这个 Field。

Pattern

Pattern 实际定义了一个指令的 decode 方式。Decodetree 会根据 Patterns 的定义，来动态产生出对应的 switch-case decode 判断分支。

pat_def      := identifier ( pat_elt )+
pat_elt      := fixedbit_elt | field_elt | field_ref | args_ref | fmt_ref | const_elt
fmt_ref      := '@' identifier
const_elt    := identifier '=' number

其语法由用户所定义的 identifier，随后紧接着一个以上的 pat_elt。

identifier 可由开发者自订，如：addl_r、addli … 等。
pat_elt 则可以采用以下不同的语法：
- fixedbit_elt 与在 Format 中 fixedbit_elt 的定义相同。
- field_elt 与在 Format 中 field_elt 的定义相同。
- field_ref 与在 Format 中 field_ref 的定义相同。
- args_ref 与在 Format 中 args_ref 的定义相同。
- fmt_ref 直接参考一个被定义过的Format。
- const_elt 可以直接指定某一个 argument 的值。

由于 Pattern 实际定义了一个指令的 decode 方式，因此所有的 bits 及 arguments (如果有参考 args_ref 的话) 都必须明确的被定义，如果在搭配了所有的 pat_elt 后还有未定义的 bits 或是 arguments 的话，Decodetree 便会报错。

此外，Pattern 所产生出来的 decoder，最后还会调用对应的 translator function。translator function 需开发者自行定义。

Pattern 示例

addl_i   010000 ..... ..... .... 0000000 ..... @opi

定义了 addl_i 这个指令的 Pattern，其中：

insn[31:26] 为 010000。
insn[11:5] 为 0000000。
参考了 Format 示例中定义的 @opi Format。
由于 Pattern 的所有 bits 都必须明确的被定义，因此 @opi 必须包含其余 insn[25:12] 及 insn[4:0] 的格式定义，否则 Decodetree 便会报错。

最后 addl_i 的 decoder 还会调用 trans_addl_i() 这个 translator function。

搭配之前介绍的 Fields、Argument Sets 及 Formats，让我们再看几个完整的例子应该会更清楚 Decodetree 是怎产生一个指令的 decoder 的。

首先是 RISC-V 的 lui 及 auipc 指令：

Responsive Image

# Fields:
%rd        7:5

# immediates:
%imm_u    12:s20                 !function=ex_shift_12

# Argument sets:
&u    imm rd

# Formats:
@u       ....................      ..... ....... &u      imm=%imm_u          %rd

# Patterns
lui      ....................       ..... 0110111 @u
auipc    ....................       ..... 0010111 @u

会产生以下 lui 及 auipc 的 decoder：

typedef struct {
    int imm;
    int rd;
} arg_u;


static void decode_insn32_extract_u(DisasContext *ctx, arg_u *a, uint32_t insn)
{
    a->imm = ex_shift_12(ctx, sextract32(insn, 12, 20));
    a->rd = extract32(insn, 7, 5);
}

static bool decode_insn32(DisasContext *ctx, uint32_t insn)
{
    union {
        arg_u f_u;
    } u;

    decode_insn32_extract_u(ctx, &u.f_u, insn);
    switch (insn & 0x0000007f) {
    case 0x00000017:
    
    
        if (trans_auipc(ctx, &u.f_u)) return true;
        return false;
    case 0x00000037:
    
    
        if (trans_lui(ctx, &u.f_u)) return true;
        return false;
    }
    return false;
}

回顾到目前为止所介绍的：

Argument Sets：&u 这个 argument set 包含了 imm 及 rd 这两个 arguments。
```
typedef struct {
    int imm;
    int rd;
} arg_u;
```
Fields： imm 及 rd 分别位在 insn[31:12] 及 insn[11:7]，且 imm 为符号扩展。最后在截取出 imm 的值后，还会调用 ex_shift_12()。
```
a->imm = ex_shift_12(ctx, sextract32(insn, 12, 20));
a->rd = extract32(insn, 7, 5);
```
Formats：@u 定义了 RISC-V U-type 指令的格式
- 参考了 &u 这个 Argument Set，因此 decode function 会传入 arg_u 作为参数。
- insn[31:12] 参考了 imm_u 这个 Field (并重命名为 imm)
- insn[11:7] 参考了 rd 这个 Field。
```
static void decode_insn32_extract_u(DisasContext *ctx, arg_u *a, uint32_t insn)
{
    a->imm = ex_shift_12(ctx, sextract32(insn, 12, 20));
    a->rd = extract32(insn, 7, 5);
}
```
Patterns：
- lui 的 opcode (insn[6:0]) 为 0010111，也就是 0x17，在产生出来的 switch-case 中可以看到其对应的 case。
- lui 的 decoder 最后调用了 trans_lui()，并传入 DisasContext 及经由 decode_insn32_extract_u() 所解析出来的 arg_u。
- auipc 的 opcode (insn[6:0]) 为 0110111，也就是 0x37，在产生出来的 switch-case 中可以看到其对应的 case。
- auipc 的 decoder 最后调用了 trans_auipc()，并传入 DisasContext 及经由 decode_insn32_extract_u() 所解析出来的 arg_u。
- P.S. 这边由于 Decodetree 发现 lui 及 auipc 可以共用 decode_insn32_extract_u()，因此将其提到了 switch-case 之外。
```
static bool decode_insn32(DisasContext *ctx, uint32_t insn)
{
    union {
        arg_u f_u;
    } u;

    decode_insn32_extract_u(ctx, &u.f_u, insn);
    switch (insn & 0x0000007f) {
    case 0x00000017:


        if (trans_auipc(ctx, &u.f_u)) return true;
        return false;
    case 0x00000037:


        if (trans_lui(ctx, &u.f_u)) return true;
        return false;
    }
    return false;
}
```
我们另外可以发现，Pattern + Format 把所有的 32-bits 都给了明确的定义：
- Pattern 定义了 opcode (insn[6:0])。
- Format 参考了 imm (insn[31:12]) 及 rd (insn[11:7])。
如果有任何未明确定义的 bits 的话，Decodetree 便会报错，例如如果我们将 lui 的 opcode 最高 2 个 bits (insn[6:5]) 由 01 改成 ..：
```
lui      ....................       ..... ..10111 @u
```
Decodetree 在解析时，便会报错：

./insn32.decode:17: error: (‘bits left unspecified (0x00000060)’,)

Decodetree 提醒我们，insn[6:5] (0x00000060) 尚未给出明确定义，并会显示出其错误的行数。

trans_lui() 和 trans_auipc() 被定义在 target/riscv/insn_trans/trans_rvi.inc.c：
```
static bool trans_lui(DisasContext *ctx, arg_lui *a)
{
    if (a->rd != 0) {
        tcg_gen_movi_tl(cpu_gpr[a->rd], a->imm);
    }
    return true;
}

static bool trans_auipc(DisasContext *ctx, arg_auipc *a)
{
    if (a->rd != 0) {
        tcg_gen_movi_tl(cpu_gpr[a->rd], a->imm + ctx->base.pc_next);
    }
    return true;
}
```
可以看到 trans_*() 负责实际指令的业务逻辑及产生对应的 TCG codes。

如同先前所介绍，Patterns 的 pat_elt 也可以采用 field_elt 语法，如 RISC-V 的 fence 指令：

fence    ---- pred:4 succ:4 ----- 000 ----- 0001111

insn[27:24] 为 pred。
insn[23:20] 为 succ。
insn[14:12] 固定为 000。
insn[6:0] 为 opcode (0001111)。
没有参考任何的 Format。
剩下的 insn[31:28]、insn[19:15]、insn[11:7] 被声明为 -，因此就算没有被明确定义也没有关系。

所生成 fence 的 decoder 如下：

typedef struct {
    int pred;
    int succ;
} arg_decode_insn320;


static void decode_insn32_extract_decode_insn32_Fmt_0(DisasContext *ctx, arg_decode_insn320 *a, uint32_t insn)
{
    a->pred = extract32(insn, 24, 4);
    a->succ = extract32(insn, 20, 4);
}

static bool decode_insn32(DisasContext *ctx, uint32_t insn)
{
    union {
        arg_decode_insn320 f_decode_insn320;
    } u;

    decode_insn32_extract_decode_insn32_Fmt_0(ctx, &u.f_decode_insn320, insn);
    switch (insn & 0x0000707f) {
    case 0x0000000f:
    
    
        if (trans_fence(ctx, &u.f_decode_insn320)) return true;
        return false;
    }
    return false;
}

值得注意的是，虽然这次我们没有参考任何的 Argument Set，但 Decodetree 还是替我们生成了一个包含 pred 和 succ 的 arg_decode_insn320 。

trans_fence() 同样是被定义在 ./target/riscv/insn_trans/trans_rvi.inc.c：

static bool trans_fence(DisasContext *ctx, arg_fence *a)
{
  
    tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC);
    return true;
}

Pattern Groups

Pattern Groups 由一个以上的 Patterns 所组成，其主要差别是不同 Patterns 之间的 bits 可以 overlap。当同组中有多个 Patterns 时，会依据该组中各 Pattern 的声明顺序依序判断目前的指令是否符合其定义。除此之外，当符合的 Pattern 其 trans_*() 回传值为 false 时，也会被视为不相符，而继续判断该组中的下一个 Pattern。因此 Pattern Groups 非常适合将多个相似格式的指令给组成同一个 Pattern Group。

group    := '{' ( pat_def | group )+ '}'

各 Pattern Group 以 { 开头，并以 } 结尾，且允许 nested pattern groups 的存在，其他语法皆与 Pattern 相同。

Pattern Group 示例

{
  {
    nop   000010 ----- ----- 0000 001001 0 00000
    copy  000010 00000 r1:5  0000 001001 0 rt:5
  }
  or      000010 rt2:5 r1:5  cf:4 001001 0 rt:5
}

会产生以下的 decoder：

switch (insn & 0xfc000fe0) {
case 0x08000240:
  
    if ((insn & 0x0000f000) == 0x00000000) {
    
        if ((insn & 0x0000001f) == 0x00000000) {
        
            extract_decode_Fmt_0(&u.f_decode0, insn);
            if (trans_nop(ctx, &u.f_decode0)) return true;
				
      }
      if ((insn & 0x03e00000) == 0x00000000) {
      
          extract_decode_Fmt_1(&u.f_decode1, insn);
          if (trans_copy(ctx, &u.f_decode1)) return true;
				　
      }
  }
  extract_decode_Fmt_2(&u.f_decode2, insn);
  if (trans_or(ctx, &u.f_decode2)) return true;
  return false;
}

当指令的值符合 nop 及 copy 这个内层 Pattern Group 时，会先判断该指令是否符合 nop 指令的定义，且 trans_nop() 的回传值为 true。否则的话，就会继续判断是否符合同组中的 copy 指令。若都不符，就会再判断是否符合外层 Pattern Group 的 or 指令。若仍不符，才会回传 false 表示 decode 失败。

与单纯使用 Pattern 最大不同的是，当一 Pattern 的 trans_*() 回传值为 false 时，不会直接回传 false (代表 decode 失败)，而是会接续着判断后续的 Patterns 是否相符。

RISC-V Compressed-Extension 中的 c.ebreak、c.jalr、及 c.add 指令，由于这三个指令的格式非常相似，因此非常适合使用 Pattern Group 来定义：

RISC-V spec. 中定义：

Responsive Image

C.EBREAK指令与C.ADD指令共享相同的opcode，但是rd和rs2都为zero，因此也可以使用CR格式。
C.JALR指令只有在rs1≠x0时才有效；当rs1=x0时，对应的代码点是C.EBREAK指令。
C.ADD指令只有在rs2≠x0时才有效；当rs2=x0时，对应的代码点是C.JALR和C.EBREAK指令。具有rs2̸=x0和rd=x0的代码点是HINTs。

c.ebreak、c.jalr、c.add 三个指令：

insn[15:13]、insn[12]、insn[1:0] 的值皆相同。
当 insn[11:7] 且 insn[6:2] 的值皆为 0 (rs1=0 且 rs2=0) 时为 c.ebreak 指令。
当只有 insn[11:7] 的值为 0 (rs1=0 且 rs2≠0) 时为 c.jalr 指令。
否则为 c.add 指令 (rs1≠x0 且 rs2≠0)。

# Fields
%rd        7:5
%rs2_5     2:5

# Argument Sets
&r         rd rs1 rs2   !extern
&i         imm rs1 rd   !extern

# Formats
@cr        ....  ..... .....  .. &r      rs2=%rs2_5       rs1=%rd     %rd
@c_jalr    ... . .....  ..... .. &i      imm=0 rs1=%rd

# Pattern Groups
{
  ebreak          100 1  00000  00000 10
  jalr            100 1  .....  00000 10 @c_jalr rd=1  # C.JALR
  add             100 1  .....  ..... 10 @cr
}

所生成的 decoder 如下：

static void decode_insn16_extract_c_jalr(DisasContext *ctx, arg_i *a, uint16_t insn)
{
    a->imm = 0; 
    a->rs1 = extract32(insn, 7, 5);
}

static void decode_insn16_extract_cr(DisasContext *ctx, arg_r *a, uint16_t insn)
{
    a->rs2 = extract32(insn, 2, 5);
    a->rs1 = extract32(insn, 7, 5);
    a->rd = extract32(insn, 7, 5);
}

static void decode_insn16_extract_decode_insn16_Fmt_2(DisasContext *ctx, arg_decode_insn162 *a, uint16_t insn)
{}


static bool decode_insn16(DisasContext *ctx, uint16_t insn)
{
    union {
        arg_decode_insn162 f_decode_insn162;
        arg_i f_i;
        arg_r f_r;
    } u;

    switch (insn & 0x0000f003) {
    case 0x00009002:
    
        if ((insn & 0x00000ffc) == 0x00000000) {
        
        
            decode_insn16_extract_decode_insn16_Fmt_2(ctx, &u.f_decode_insn162, insn);
            if (trans_ebreak(ctx, &u.f_decode_insn162)) return true;
        
        }
        if ((insn & 0x0000007c) == 0x00000000) {
        
        
            decode_insn16_extract_c_jalr(ctx, &u.f_i, insn);
            u.f_i.rd = 1; 
            if (trans_jalr(ctx, &u.f_i)) return true;
        
        }
    
        decode_insn16_extract_cr(ctx, &u.f_r, insn);
        if (trans_add(ctx, &u.f_r)) return true;
        return false;
    }
    return false;
}

当指令格式符合 c.ebreak、c.jalr、c.add 的 Pattern Group 时，会依序判断该指令是否符合 c.ebreak、c.jalr、c.add 的定义以及其对应的 trans_*()。

另外值得一提的是，在 c_jalr Format 和 jalr Pattern 中有分别指定其 imm 及 rd 的值为 0，所生成的 codes 也会分别在对应的地方将该值设为 0 (见 codes 注解说明)。

总结

以上就是 Decodetree 的语法说明。通过 Decodetree，我们不用再像以前以样写一大包的 switch-case 来 decode 指令。将不同类型的指令写至不同的 decode 档，不仅方便维护，阅读起来也更为容易。

--translate：translator function 的 prefix，默认为 trans。一旦指定后，translator function 的 scope 就不会再是 static。
--decode：decode function 的 prefix，默认为 decode，且 scope 为 static。一旦指定后，decode function 的 scope 就不会再是 static。
--static-decode：如同 --decode，不过 decode function 的 scope 仍维持为 static。
-o / --output：指定生成的 decoder .c 档路径。
-w / --insnwidth：指令长度，eg：32 or 16，默认为 32。
--varinsnwidth：指令为不定长度。
最后一个参数为输入的 decode 档路径。

运行范例：

./decodetree.py -o target/riscv/decode_insn16.inc.c --static-decode decode_insn16 \
    -w 16 ./insn16.decode

static inline int32_t sextract32(uint32_t value, int start, int length){    assert(start >= 0 && length > 0 && length <= 32 - start);        return ((int32_t)(value << (32 - length - start))) >> (32 - length);}

QEMU 常用命令

Sun, 07 Jul 2024 10:22:12 +0000

QEMU 是一个开源的虚拟化软件，它能够模拟不同的硬件平台，让用户在不同的操作系统之间进行切换和测试。以下是 QEMU 常用命令的总结文档，包含每个命令的功能说明。

QEMU 安装

源码下载

压缩包方式

版本可以修改

cd qemu-build && wget  "https://download.qemu.org/qemu-8.0.2.tar.xz"

tar -xf qemu-8.0.2.tar.xz --strip-components=1

Clone 方式

git clone https://gitlab.com/qemu-project/qemu.git
cd qemu
git submodule init
git submodule update --recursive

配置编译选项

./configure --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-linux-user,riscv64-softmmu \
--enable-kvm \
--enable-debug \
--enable-sdl \
--prefix=/home/user/program/riscv64-qemu \
--python=/usr/bin/python3
# --python=python路径，如果提示默认python版本低，可以加这个参数
# --prefix 选项设置qemu的安装位置绝对路径，之后若要卸载删除qemu只要删除该文件夹即可，--enable-kvm开启kvm
# config完，可以在指定的qemu安装文件夹下面找到config-host.mak文件，
# 该文件记录着qemu配置的选项，可以和自己设置的进行对比，确保配置和自己已知

一些常用的编译选项

–enable-debug：编译调试版本，调试版本的运行速度非常慢
–disable-werror：忽略警告，否则任何编译警告都被视为编译错误
–enable-plugins：开启TCG Plugin支持
–disable-stack-protector：关闭QEMU自身的栈保护
–extra-cflags="-O3"：能让你的QEMU提速5~10%，如果编译时报错，请加上--disable-werror
–prefix=<路径>：指定安装目录的路径
–target-list=<架构>：指定要编译的目标架构列表，例如 x86_64-softmmu,arm-softmmu。
–enable-<功能>：启用指定的功能。例如，--enable-kvm 启用 KVM 支持，--enable-gtk 启用 GTK 图形界面等。
–disable-<功能>：禁用指定的功能。
–enable-debug：启用调试模式，包括调试符号和调试输出。
–enable-virtfs：启用 virtio 文件系统支持。
–enable-modules：启用模块支持。
–disable-guest-agent：禁用客户机代理支持。
–enable-trace-backend=<后端>：指定跟踪后端，例如 simple、log 或 dtrace。
–disable-vhost-net：禁用 vhost-net 支持。

编译时输出.i 文件用于查看宏定义展开

$ ./configure  --extra-cflags="-save-temps"   --target-list=riscv64-linux-user,riscv64-softmmu --disable-werror  --python=/usr/bin/python3

启动虚拟机

以下命令用于启动虚拟机：

qemu-system-x86_64 -boot d -cdrom /path/to/iso -m 1024 -hda /path/to/hda.img

-boot d：从 CD/DVD 启动
-cdrom /path/to/iso：指定 ISO 文件的路径
-m 1024：设置虚拟机的内存大小为 1024MB
-hda /path/to/hda.img：指定虚拟硬盘的路径

安装系统至磁盘

qemu-system-x86_64 \
    -cdrom ~/Downloads/ubuntu.iso \
    -drive file=ubuntu.qcow2 \
    -enable-kvm \
    -cpu host \
    -smp cores=2,threads=2 \
    -m 2G \
    -vga virtio \
    -display sdl,gl=on

网络配置

以下命令用于配置虚拟机的网络：

qemu-system-x86_64 -net nic -net user,hostfwd=tcp::2222-:22

-net nic：启用虚拟网卡
-net user：使用用户模式网络堆栈
hostfwd=tcp::2222-:22：将主机的 2222 端口转发到虚拟机的 22 端口

调试相关命令

启动调试模式

qemu-system-x86_64 -s -S

-s：启用 GDB 调试
-S：在启动时暂停虚拟机，等待调试器连接

输出调试日志

/home/user/develop/qemu/build/qemu-riscv64 -d in_asm,exec,cpu,strace -D ./log hello

QEMU 的 -d 参数说明

日志选项（用逗号分隔）：

out_asm：显示每个已编译基本块生成的宿主汇编代码
in_asm：显示每个已编译基本块的目标汇编代码
op：显示每个已编译基本块的微操作
op_opt：显示优化后的微操作
op_ind：显示间接降低前的微操作
int：以简短格式显示中断/异常
exec：在每次执行基本块前显示跟踪（大量日志）
cpu：在进入基本块前显示 CPU 寄存器（大量日志）
fpu：在“cpu”日志中包含 FPU 寄存器
mmu：记录与 MMU 相关的活动
pcall：仅限 x86：显示保护模式下的远程调用/返回/异常
cpu_reset：在 CPU 重置前显示 CPU 状态
unimp：记录未实现的功能
guest_errors：当来宾操作系统执行无效操作（例如访问不存在的寄存器）时记录日志
page：在用户模式仿真开始时转储页面
nochain：不链式编译基本块，以便“exec”和“cpu”显示完整的跟踪
plugin：输出来自 TCG 插件的信息
strace：记录每个用户模式系统调用、其输入和结果
trace:PATTERN：启用跟踪事件

使用 "-d trace:help" 来获取跟踪事件列表。

qemu-system-xxx 常用相关参数

-M：指定 machine，-help 可以列出所有所支持的 machine
-cpu：指定模拟的 CPU 型号，例如 cortex-a57、cortex-a53 等。
-smp：CPU 核数
-m：RAM 容量
-kernel：Linux kernel 文件
-append：Linux Kernel 的 bootargs。这个命令的参数很复杂，具体可以参考 kernel 文档。
-console：设备名必须和 machine 的串口一致，否则会看不到 kernel log。而不同的平台 console 名称都是不一样的，这是 Kernel 很不友好的一点。
-ignore_loglevel：可以让你看到尽可能多的 kernel log，当然也会减慢 kernel 的启动速度
-init：必须保证 initrd 里有/linuxrc 这个文件，否则会无法启动 shell
-initrd：指定 initrd 文件

快照管理

# 拍快照
qemu-img snapshot -c oe-rv-snapshot1  openEuler-22.09-riscv64-qemu.qcow2
# 列举快照
qemu-img snapshot-l openEuler-22.09-riscv64-qemu.qcow2
# 恢复快照
qemu-img snapshot -a my_snapshot mydisk.qcow2

查看虚拟硬盘信息

qemu-img info /path/to/image

将虚拟硬盘转换为 QCOW2 格式

qemu-img convert -O qcow2 /path/to/image /path/to/new/image

调整磁盘大小

qemu-img resize ubuntu.qcow2 +5G

显示器选项

qemu-system-x86_64 -vga std
qemu-system-x86_64 -display sdl
qemu-system-x86_64 -display gtk

-vga std：使用标准 VGA 显示器
-display sdl：使用 SDL 显示器
-display gtk：使用 GTK 显示器

输入选项

qemu-system-x86_64 -k en-us
qemu-system-x86_64 -usb
qemu-system-x86_64 -device usb-mouse

-k en-us：使用英文键盘布局
-usb：启用 USB 支持
-device usb-mouse：使用 USB 鼠标设备

声音选项

以下命令用于配置虚拟机的声音：

qemu-system-x86_64 -soundhw all
qemu-system-x86_64 -soundhw sb16
qemu-system-x86_64 -audiodev pa,id=pa1,out.mixing-engine=off

-soundhw all：启用所有声卡
-soundhw sb16：启用 SoundBlaster 16 声卡
-audiodev pa,id=pa1,out.mixing-engine=off：使用 PulseAudio 声音设备

USB 设备管理

以下命令用于管理虚拟机的 USB 设备：

qemu-system-x86_64 -usbdevice host:1234:5678
qemu-system-x86_64 -usbdevice tablet
qemu-system-x86_64 -usbdevice keyboard

-usbdevice host🔢5678：将主机的 USB 设备 1234:5678 分配给虚拟机
-usbdevice tablet：使用 USB 触摸板
-usbdevice keyboard：使用 USB 键盘

QEMU 虚拟机网络配置

Sat, 05 Aug 2023 14:47:54 +0000

Quick Setup

安装工具

安装两个网络管理工具用于建立网桥以及虚拟网卡：

# 安装虚拟网桥工具
sudo apt install bridge-utils -y
# UML（User-mode linux）工具        
sudo apt install uml-utilities  -y

配置脚本

qemu-ifup

将下面的脚本保存为文件 qemu-ifup，并赋予可执行权限：

为了方便复制脚本，在 confluence 页面提供了脚本内容，可以直接复制。

mkdir -p /etc/qemu
mv qemu-ifup /etc/qemu && mv qemu-ifdown /etc/qemu 
sudo chmod +x qemu-ifup
sudo chmod +x qemu-ifdown

因为网卡信息不容易定位，可能一台机器有多个网卡，所以不方便用脚本获取，需要手动设置一下。将下面的NIC值修改为宿主机可以上网的网卡名称。可以通过ifconfig命令查看。

#!/bin/bash
# 设置默认网卡信息
NIC=enp2s0
# 设置用户名
USER_NAME=user
# 设置网桥名称
BRIDGE=br0
# 设置网络信息
NIC_IP=$(ifconfig $NIC | grep "inet\b" | awk '{print $2}')

NIC_NETMAST=$(ifconfig $NIC | grep "inet\b" | awk '{print $4}')

NIC_BROADCAST=$(ifconfig $NIC | grep "inet\b" | awk '{print $6}')

NETMASK=255.255.240.0
# 设置默认网关地址
GATEWAY=10.12.192.1

# 获取宿主机网卡MAC地址，因为创建的网桥MAC地址是随机的，
# 无法接入公司，需要从开发机网卡将其MAC地址赋值给网桥
MAC=$(ifconfig $NIC | grep "ether\b" | awk '{print $2}')

# 检查网桥是否已创建，已创建就忽略
function check_bridge() 
{
    echO "Check bridge..."
    if brctl show | grep "^$BRIDGE" &> /dev/null; then
        return 1
    else
        return 0
    fi
}

# 创建网桥
function create_bridge() 
{
    echo "Start Create bridge..."
    brctl addbr "$BRIDGE"
    brctl addif "$BRIDGE"  "$NIC"
    ifconfig br0 0.0.0.0 promisc up
    dhclient $BRIDGE
}

# ifconfig "$BRIDGE" "$NIC_IP" netmask "$NIC_NETMAST" broadcast "$NIC_BROADCAST"  hw ether "$MAC" promisc up

# 启用IP转发
function enable_ip_forward() 
{
    echo 1 > /proc/sys/net/ipv4/ip_forward
}

# 设置网桥
function setup_bridge()
{
    check_bridge "$BRIDGE"
    if [ $? -eq 0 ]; then
        create_bridge
    fi
    enable_ip_forward
}

if [ -n "$1" ]; then
    setup_bridge
    echo "Creating $1..."
    tunctl -t "$1" -u "$USER_NAME"
    ifconfig "$1" 0.0.0.0 up
    echo "Adding $1 to $BRIDGE..."
    brctl addif "$BRIDGE" "$1"
    sleep 5
    ifconfig "$BRIDGE"  hw ether "$MAC" promisc up
    exit 0
else
    echo "Error: no interface specified."
    exit 1
fi

qemu-ifdown

以下是qemu-ifdown脚本，用于在关闭 QEMU 时关闭虚拟网卡，将其从网桥中移除，删除虚拟网卡。

#!/bin/bash
# 设置网桥名称
BRIDGE=br0

if [ -n "$1" ]; then
    # 将tap设备从网桥中移除
	brctl delif ${BRIDGE} $1
	# 关闭tap设备
	ip link link $1 down
    # 删除tap设备
    ip link del "$1"
	tunctl -d "$1"
	exit 0
else
	echo "Error: no interface specified"
	exit 1
fi

将系统镜像复制一份并修改文件名，QEMU 不能同时使用一个镜像启动两个虚拟机。

cp openEuler-22.09-riscv64-qemu.qcow2 openEuler-22.09-riscv64-qemu-vm1.qcow2

需要修改启动脚本中的镜像文件名，以及启动参数，将drive以及cmd变量的内容覆盖为下面的内容，修改mac为分配给自己的虚拟机的 MAC 地址，script为上面的脚本qemu-ifup的路径。

# 该脚本用于启动VM0
drive="openEuler-22.09-riscv64-qemu.qcow2"
....
cmd="qemu-system-riscv64 \
  -nographic -machine virt \
  -smp "$vcpu" -m "$memory"G \
  -bios "$fw" \
  -drive file="$drive",format=qcow2,id=hd0 \
  -object rng-random,filename=/dev/urandom,id=rng0 \
  -device virtio-vga \
  -device virtio-rng-device,rng=rng0 \
  -device virtio-blk-device,drive=hd0 \
  -device virtio-net-device,netdev=tapnet,mac=e0:be:03:88:54:e8 \
  -netdev tap,id=tapnet,script=/etc/qemu/qemu-ifup,downscript=/etc/qemu/qemu-ifdown \
  -device qemu-xhci -usb -device usb-kbd -device usb-tablet"

以sudo权限启动脚本：

sudo ./preview_start_vm0.sh

以下为配置 VM1 过程，VM1 的启动脚本与 VM0 的启动脚本类似，只需要修改drive以及MAC，必须保证MAC与 VM0 的MAC不同。

# 该脚本用于启动VM1
drive="openEuler-22.09-riscv64-qemu.qcow2"
....
cmd="qemu-system-riscv64 \
  -nographic -machine virt \
  -smp "$vcpu" -m "$memory"G \
  -bios "$fw" \
  -drive file="$drive",format=qcow2,id=hd0 \
  -object rng-random,filename=/dev/urandom,id=rng0 \
  -device virtio-vga \
  -device virtio-rng-device,rng=rng0 \
  -device virtio-blk-device,drive=hd0 \
  -device virtio-net-device,netdev=tapnet,mac=80:d4:09:62:cd:3c \
  -netdev tap,id=tapnet,script=/etc/qemu/qemu-ifup,downscript=/etc/qemu/qemu-ifdown \
  -device qemu-xhci -usb -device usb-kbd -device usb-tablet"

网络通信测试

当前网络状态如下：

HOST:10.12.192.177
VM0:10.12.193.53
VM1:10.12.193.101

HOST –> VM0

# user @ ubuntu18 in ~/openeuler/openEuler2209 [18:41:54] 
$ ping -c 3 10.12.193.101
PING 10.12.193.101 (10.12.193.101) 56(84) bytes of data.
64 bytes from 10.12.193.101: icmp_seq=1 ttl=64 time=1.37 ms
64 bytes from 10.12.193.101: icmp_seq=2 ttl=64 time=0.897 ms
64 bytes from 10.12.193.101: icmp_seq=3 ttl=64 time=0.890 ms

--- 10.12.193.101 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.890/1.055/1.378/0.228 ms

Host –> VM1 的测试结果与 Host –> VM0 的测试结果相同。

VM0 –> HOST

[root@openEuler-riscv64 ~]# ping -c 3 10.12.193.53 
PING 10.12.193.53 (10.12.193.53) 56(84) bytes of data.
64 bytes from 10.12.193.53: icmp_seq=1 ttl=64 time=0.716 ms
64 bytes from 10.12.193.53: icmp_seq=2 ttl=64 time=1.74 ms
64 bytes from 10.12.193.53: icmp_seq=3 ttl=64 time=1.81 ms

--- 10.12.193.53 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 0.716/1.424/1.812/0.501 ms

VM1 –> Host 的测试结果与 Host –> VM0 的测试结果相同。

VM1 –> VM0

[root@openEuler-riscv64 ~]# ping -c 3 10.12.193.53 
PING 10.12.193.53 (10.12.193.53) 56(84) bytes of data.
64 bytes from 10.12.193.53: icmp_seq=1 ttl=64 time=0.716 ms
64 bytes from 10.12.193.53: icmp_seq=2 ttl=64 time=1.74 ms
64 bytes from 10.12.193.53: icmp_seq=3 ttl=64 time=1.81 ms

--- 10.12.193.53 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 0.716/1.424/1.812/0.501 ms

VM0 –> VM1 与 VM1 –> VM0 的测试结果相同。

VM0 –> github

[root@openEuler-riscv64 ~]# ping -c 4 github.com
PING github.com (192.30.255.113) 56(84) bytes of data.
64 bytes from lb-192-30-255-113-sea.github.com (192.30.255.113): icmp_seq=1 ttl=46 time=221 ms
64 bytes from lb-192-30-255-113-sea.github.com (192.30.255.113): icmp_seq=2 ttl=46 time=277 ms
64 bytes from lb-192-30-255-113-sea.github.com (192.30.255.113): icmp_seq=3 ttl=46 time=216 ms
64 bytes from lb-192-30-255-113-sea.github.com (192.30.255.113): icmp_seq=4 ttl=46 time=218 ms

--- github.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3014ms
rtt min/avg/max/mdev = 215.984/232.733/276.593/25.374 ms

HOST –> github

# user @ ubuntu18 in ~/openeuler/openEuler2209 [17:59:40] 
$ ping -c 3  github.com
PING github.com (192.30.255.113) 56(84) bytes of data.
64 bytes from lb-192-30-255-113-sea.github.com (192.30.255.113): icmp_seq=1 ttl=46 time=218 ms
64 bytes from lb-192-30-255-113-sea.github.com (192.30.255.113): icmp_seq=2 ttl=46 time=216 ms
64 bytes from lb-192-30-255-113-sea.github.com (192.30.255.113): icmp_seq=3 ttl=46 time=216 ms

--- github.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 216.252/217.087/218.409/0.945 ms

原理探究 (Ongoing)

Step by Step 解析

查看一下网络接口信息：

ifconfig
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.12.192.173  netmask 255.255.240.0  broadcast 10.12.207.255
        inet6 fe80::a00:27ff:fe32:e709  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:32:e7:09  txqueuelen 1000  (Ethernet)
        RX packets 6017  bytes 5412928 (5.4 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1979  bytes 179467 (179.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 125  bytes 10142 (10.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 125  bytes 10142 (10.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

创建一个名为br0的网桥

sudo brctl addbr br0

将网桥与宿主机的网卡绑定

sudo brctl addif br0 enp3s0

启用 br0 接口，并从 DHCP 服务器获得 IP 地址

sudo ifconfig br0 0.0.0.0 promisc up
sudo dhclient br0

查看虚拟网桥列表

sudo brctl show br0

bridge name	    bridge id		    STP enabled    interfaces
br0		            8000.e0be0388eec9  no             enp3s0

查看 br0 的各接口信息

sudo brctl showstp br0
br0
 bridge id		8000.e0be0388eec9
 designated root	8000.e0be0388eec9
 root port			0			path cost 0
 max age			20.00s
 forward delay		15.00s
 hello time			2.00s
 ageing time		300.00s
 hello timer		0.00s		<tbd>
 forward timer		0.00s		<tbd>
 ageing timer		0.00s		<tbd>
 
 enp3s0 (1)
 port id			8001			local state forwarding
 designated root	8000.08002732e709
 path cost			100
 designated bridge	8000.08002732e709
 designated port	8001
 forward delay		15.00s
 hello time			2.00s
 max age			20.00s
 ageing time		300.00s
 priority			128

当前网络拓扑：

            +-----------------------------------+
            |          Internet                 |
            +-----------------------------------+
                             |
                             |
                             v
+---------------------------------------------------------+
|                   enp3s0 (Host Interface)               |
|                   IP: 10.12.192.173                     |
+---------------------------------------------------------+
                            |
                            v
+---------------------------------------------------------+
|                         br0 (Bridge)                    |
|                      IP: 10.12.192.173                  |
+---------------------------------------------------------+

创建一个 tap0 接口用于VM0使用，允许 user 用户访问

sudo tunctl -t tap0 -u user

在虚拟网桥中增加 tap0 接口

sudo brctl addif br0 tap0

启用 tap0 接口，混杂模式

sudo ifconfig tap0 0.0.0.0 promisc up

将网桥的 MAC 地址修改为宿主机的 MAC 地址，这样就可以接入公司网络了。否则因为内网的 MAC 地址过滤，无法接入公司网络。

ifconfig br0  hw ether 08:00:27:32:e7:09  promisc up

查看虚拟网桥列表

$ sudo brctl show br0

bridge name	    bridge id		    STP enabled    interfaces
br0		            8000.08002732e709  no             enp3s0
                                                        tap0

查看当前的网桥状态：

$ sudo brctl showstp br0 
br0
 bridge id		8000.08002732e709
 designated root	8000.08002732e709
 root port		   0			path cost		   0
 max age		  20.00			bridge max age		  20.00
 hello time		   2.00			bridge hello time	   2.00
 forward delay		  15.00			bridge forward delay	  15.00
 ageing time		 300.00
 hello timer		   0.00			tcn timer		   0.00
 topology change timer	   0.00			gc timer		   7.75
 flags			


enp2s0 (1)
 port id		8001			state		     forwarding
 designated root	8000.08002732e709	path cost		   4
 designated bridge	8000.08002732e709	message age timer	   0.00
 designated port	8001			forward delay timer	   0.00
 designated cost	   0			hold timer		   0.00
 flags			

tap0 (2)
 port id		8002			state		     disabled
 designated root	8000.08002732e709	path cost		 100
 designated bridge	8000.08002732e709	message age timer	   0.00
 designated port	8002			forward delay timer	   0.00
 designated cost	   0			hold timer		   0.00
 flags

tap0可能处于disabled状态，因为还没有虚拟机使用它。启动虚拟机之后会自动切换到forwarding状态。

当前网络拓扑：

            +-----------------------------------+
            |          Internet                 |
            +-----------------------------------+
                             |
                             |
                             v
+---------------------------------------------------------+
|                   enp3s0 (Host Interface)               |
|                   IP: 10.12.192.173                     |
+---------------------------------------------------------+
                            |
                            v
+---------------------------------------------------------+
|                         br0 (Bridge)                    |
|                      IP: 10.12.192.173                  |
|                  +---------------------+                |
|                  |        tap0         |                |
|                  |     IP: 0.0.0.0     |                |
+---------------------------------------------------------+

启动 QEMU

cmd="qemu-system-riscv64 \
  -nographic -machine virt \
  -smp "$vcpu" -m "$memory"G \
  -bios "$fw" \
  -drive file="$drive",format=qcow2,id=hd0 \
  -object rng-random,filename=/dev/urandom,id=rng0 \
  -device virtio-vga \
  -device virtio-rng-device,rng=rng0 \
  -device virtio-blk-device,drive=hd0 \
  -device virtio-net-device,netdev=tapnet,mac=e0:be:03:88:54:e8 \
  -netdev tap,id=tapnet,ifname=tap0,script=no,downscript=no \
  -device qemu-xhci -usb -device usb-kbd -device usb-tablet"

关注这段脚本的网络配置部分：

  -device virtio-net-device,netdev=tapnet,mac=e0:be:03:88:54:e8 \
  -netdev tap,id=tapnet,ifname=tap0,script=no,downscript=no \

详细解释可以查看“QEMU 网络虚拟化章节”，第一个参数 -device virtio-net-device 定义了名为 virtio-net-device 的网络设备，并将其连接到一个名为 tapnet 的网络设备上，指定它的 MAC 地址为 e0:be:03:88:54:e8。第二个参数 -netdev tap 用于指定后端实现，使用tap方式，并且指定唯一 ID 为tapnet由-device参数中的子参数netdev使用，指定ifname=tap0，表示使用tap0接口作为虚拟化的后端。script=no和downscript=no表示不使用脚本来启动和关闭tap0接口。

查看当前的网络接口信息ifconfig：

br0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        inet 10.12.192.173  netmask 255.255.240.0  broadcast 10.12.207.255
        inet6 fe80::e2be:3ff:fe88:eec9  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:32:e7:09  txqueuelen 1000  (Ethernet)
        RX packets 861148  bytes 310707296 (310.7 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 17556062  bytes 1516515693 (1.5 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.12.192.173  netmask 255.255.240.0  broadcast 10.12.207.255
        inet6 fe80::4964:61f8:420d:6781  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:32:e7:09  txqueuelen 1000  (Ethernet)
        RX packets 894523  bytes 325547917 (325.5 MB)
        RX errors 0  dropped 1926  overruns 0  frame 0
        TX packets 17563568  bytes 1516947572 (1.5 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1654925876  bytes 134933568498 (134.9 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1654925876  bytes 134933568498 (134.9 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::f8ae:85ff:fed7:f9cd  prefixlen 64  scopeid 0x20<link>
        ether fa:ae:85:d7:f9:cd  txqueuelen 1000  (Ethernet)
        RX packets 557  bytes 44913 (44.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7165  bytes 832171 (832.1 KB)
        TX errors 0  dropped 55942 overruns 0  carrier 0  collisions 0

当前网络拓扑：

            +-----------------------------------+
            |          Internet                 |
            +-----------------------------------+
                             |
                             |
                             v
+---------------------------------------------------------+
|                   enp3s0 (Host Interface)               |
|                   IP: 10.12.192.173                     |
+---------------------------------------------------------+
                            |
                            v
+---------------------------------------------------------+
|                         br0 (Bridge)                    |
|                      IP: 10.12.192.173                  |
|                  +---------------------+                |
|                  |        tap0         |                |
|                  |     IP: 0.0.0.0     |                |
+---------------------------|-----------------------------+
                            |
                            v
+---------------------------|-----------------------------+
|                  |        eth0         |                |
|                  |     IP:10.12.193.53 |                |
|                  +---------------------+                |
|                     VM0 (QEMU)                          |
+---------------------------------------------------------+

查看当前的网桥状态，可以看到 tap0 已经处于 forwarding 状态：

$ sudo brctl showstp br0 
br0
 bridge id		8000.08002732e709
 designated root	8000.08002732e709


enp2s0 (1)
 port id		8001			state		     forwarding
 designated root	8000.08002732e709	path cost		   4
 designated bridge	8000.08002732e709	message age 		

tap0 (2)
 port id		8002			state		     forwarding
 designated root	8000.08002732e709	path cost		 100
 designated bridge	8000.08002732e709	message age

添加 VM1 过程就忽略了，添加后的网络拓扑如下：

            +-----------------------------------+
            |          Internet                 |
            +-----------------------------------+
                             |
                             |
                             v
+---------------------------------------------------------+
|                   enp3s0 (Host Interface)               |
|                   IP: 10.12.192.173                     |
+---------------------------------------------------------+
                            |
                            v
+---------------------------------------------------------+
|                         br0 (Bridge)                    |
|                      IP: 10.12.192.173                  |
|    +---------------------+  +-------------------+       |
|    |        tap0         |  |        tap1       |       |
|    |     IP: 0.0.0.0     |  |     IP: 0.0.0.0   |       |
+---------------|-------------------------|---------------+
                |                         |
                v                         v
+---------------|----------+  +-----------|---------------+
|   |     eth0         |   |  |   |        eth0       |   |
|   |  IP:10.12.193.53 |   |  |   |  IP:10.12.193.101 |   |
|   +---------------------+|  |   +-------------------+   |
|         VM0 (QEMU)       |  |         VM1 (QEMU)        |
+--------------------------+  +---------------------------+

QEMU 网络虚拟化

QEMU 对于网络的虚拟化需要两个参数来指定：

其中一个用于指定网络的前端驱动，也就是 Guest 中的实现
另一个用于指定网络的后端实现，也就是在 Host 中的实现。

QEMU 支持两种方式来实现网络虚拟化，一种是旧版本上使用的参数为 -net 配合 -net ，另一种是在新版本上支持的 -device 配合 -netdev 。QEMU 的发展趋势是倾向于用 -device 一种命令格式来虚拟出不同的设备，其中包括网卡设备。

-net & -net (legacy)

虽然仍然支持，但是逐步被废弃，不推荐使用。

我们以以下命令为例，来说明 -net 和 -net 的使用方法：

vcpu=8
memory=8
drive="openEuler-22.09-V1-riscv64-qemu.qcow2"
fw="fw_payload_oe_qemuvirt.elf"

cmd="qemu-system-riscv64 \
  -nographic -machine virt \
  -smp "$vcpu" -m "$memory"G \
  -kernel "$fw" \
  -bios none \
  -drive file="$drive",format=qcow2,id=hd0 \
  -object rng-random,filename=/dev/urandom,id=rng0 \
  -device virtio-vga \
  -device virtio-rng-device,rng=rng0 \
  -device virtio-blk-device,drive=hd0 \
  -net nic,mac=52:54:00:12:34:56 \
  -net tap,ifname=tap0,script=no,downscript=no \
  -device qemu-xhci -usb -device usb-kbd -device usb-tablet \
  -append 'root=/dev/vda1 rw console=ttyS0 swiotlb=1 loglevel=3 systemd.default_timeout_start_sec=600 selinux=0 highres=off mem="$memory_append"M earlycon' "

其中这两个参数即实现了虚拟化网络：

  -net nic,mac=52:54:00:12:34:56 \
  -net tap,ifname=tap0,script=no,downscript=no \

第一个参数 -net nic 用于指定上述所说的前端驱动，也就是 Guest 中的实现，这里使用的是默认的驱动，这个驱动是 QEMU 中的一个虚拟网卡设备，指定它的 MAC 地址为 52:54:00:12:34:56。

第二个参数 -net tap 用于指定后端实现，也就是 Host 中的实现，这里使用的是 tap 驱动，它的网卡名称为 tap0，并且不执行任何脚本。这两个参数的组合就实现了虚拟化网络。

更多示例：

-net nic,model=virtio \
-net tap,ifname=tap3,script=/ect/qemu/qemu-ifup,downscript=no \

第一个参数 -net nic 用于指定上述所说的前端驱动，也就是 Guest 中的实现，这里使用的是 virtio 驱动，这个驱动是 QEMU 中的一个虚拟网卡设备。第二个参数 -net tap 用于指定后端实现，也就是 Host 中的实现，这里使用的是 tap 驱动，它的网卡名称为 tap3，并且执行脚本 /ect/qemu/qemu-ifup。

解释/ect/qemu/qemu-ifup 该脚本用于创建网桥，将网桥与宿主机的网卡绑定，然后将虚拟网卡绑定到网桥上，这样虚拟机就可以通过网桥与宿主机通信，宿主机也可以通过网桥与虚拟机通信。

-device & -netdev （Recommended）

这是新版本的 QEMU 支持的命令格式，也是 QEMU 未来的发展趋势，我们以以下命令为例，来说明 -device 和 -netdev 的使用方法：

qemu-system-riscv64 \
  -nographic -machine virt \
  -smp "$vcpu" -m "$memory"G \
  -bios "$fw" \
  -drive file="$drive",format=qcow2,id=hd0 \
  -object rng-random,filename=/dev/urandom,id=rng0 \
  -device virtio-vga \
  -device virtio-rng-device,rng=rng0 \
  -device virtio-blk-device,drive=hd0 \
  -device virtio-net-device,netdev=tapnet,mac=e0:be:03:88:54:e8 \
  -netdev tap,id=tapnet,ifname=tap0,script=~/qemu-script/qemu-ifup,downscript=no \
  -device qemu-xhci -usb -device usb-kbd -device usb-tablet

其中这两个参数即实现了虚拟化网络：

  -device virtio-net-device,netdev=tapnet,mac=e0:be:03:88:54:e8 \
  -netdev tap,id=tapnet,ifname=tap0,script=~/qemu-script/qemu-ifup,downscript=no \

第一个参数 -device virtio-net-device 用于指定上述所说的前端驱动，也就是 Guest 中的实现，定义了名为 virtio-net-device 的网络设备，并将其连接到一个名为 tapnet 的网络设备上，指定它的 MAC 地址为 e0:be:03:88:54:e8。

第二个参数 -netdev tap 用于指定后端实现，使用tap方式，并且指定唯一 ID 为tapnet由-device参数中的子参数netdev使用。网卡名称为tap0并且执行脚本 ~/qemu-script/qemu-ifup。

-netdev 参数中 id 的使用 -netdev 参数中的 id 用于指定唯一的 ID，这个 ID 会被 -device 参数中的子参数 netdev 使用，这样 -device 参数就知道要将前端驱动连接到哪个后端实现上了。id 可以自定义任意唯一字符串如-netdev tap,id=test对应-device virtio-net-device,netdev=test

更多示例：

  -device virtio-net-pci,netdev=tapnet,mac=e0:be:03:88:54:e8 \
  -netdev tap,id=tapnet,script=no,downscript=no \

第一个参数 -device virtio-net-pci 定义了名为 virtio-net-pci 的网络设备，并将其连接到一个名为 tapnet 的网络设备上，指定它的 MAC 地址为 e0:be:03:88:54:e8。

第二个参数，仔细观察会发现，我们没有定义链接到后端网卡的名称ifname，这是因为以tap模式启动 QEMU 时会自动创建tap设备，具体网卡名称根据当前宿主机的网卡情况而定，默认会创建一个名为tap0的网卡，如果启动了两个虚拟机，那么第二个虚拟机的网卡名称就是tap1，以此类推。

区分 tap 模式与 bridge 模式

我们有时候会用以下的命令进行 QEMU 虚拟机桥接网络的配置：

  -device virtio-net-device,netdev=bridgenet,mac=52:54:00:12:34:57 \
  -netdev bridge,ifname=br0,id=bridgenet

这也能为我们创建一个桥接网络，这是因为它和 -netdev tap 的工作方式是一样的，只是 -netdev bridge 的简化写法，qemu-bridge-helper 在背后替我们做了 tap 设备创建以及将 tap 设备加入桥接口的所有事情。

添加多张网卡

如果了解上述内容，添加多张网卡就十分容易实现了，我们只需要再添加一对 -device 和 -netdev 参数即可，如下所示：

qemu-system-riscv64 \
  -nographic -machine virt \
  -smp "$vcpu" -m "$memory"G \
  -bios "$fw" \
  -drive file="$drive",format=qcow2,id=hd0 \
  -object rng-random,filename=/dev/urandom,id=rng0 \
  -device virtio-vga \
  -device virtio-rng-device,rng=rng0 \
  -device virtio-blk-device,drive=hd0 \
  -device virtio-net-device,netdev=tapnet0,mac=e0:be:03:88:54:e8 \
  -netdev tap,id=tapnet0,script=/etc/qemu/qemu-ifup,downscript=/etc/qemu/qemu-ifdown \
  -device virtio-net-device,netdev=tapnet1,mac=e0:be:03:88:54:e8 \
  -netdev tap,id=tapnet1,script=/etc/qemu/qemu-ifup,downscript=/etc/qemu/qemu-ifdown \
  -device qemu-xhci -usb -device usb-kbd -device usb-tablet

需要注意的是，我们需要为每个 -device 参数指定一个唯一的 ID，这个 ID 会被 -netdev 参数中的子参数 netdev 使用，这样 -device 参数就知道要将前端驱动连接到哪个后端实现上了。并且每个 tap 设备只能被一个虚拟机使用，所以每个虚拟机的 tap 设备名称不能相同。

登录虚拟机查看网卡信息：

[root@openEuler-riscv64 ~]# ifconfig 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.12.193.53  netmask 255.255.240.0  broadcast 10.12.207.255
        inet6 fe80::9e6:287b:30a2:574d  prefixlen 64  scopeid 0x20<link>
        ether e0:be:03:88:54:e8  txqueuelen 1000  (Ethernet)
        RX packets 81  bytes 9871 (9.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 19  bytes 1735 (1.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.12.193.101  netmask 255.255.240.0  broadcast 10.12.207.255
        inet6 fe80::4fe0:9e1e:4681:52b7  prefixlen 64  scopeid 0x20<link>
        ether 80:d4:09:62:cd:3c  txqueuelen 1000  (Ethernet)
        RX packets 76  bytes 9471 (9.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 15  bytes 1708 (1.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

不同网络策略工作方式

NAT 网络模式
- NAT 网络以路由器的 NAT 功能为原理，允许虚拟机通过共享主机的 IP 地址访问互联网，但虚拟机之间不能直接通信。通过端口转发可以实现虚拟机之间的连接。
桥接网络模式
- 桥接网络模式通过虚拟交换机连接虚拟机和主机，使得虚拟机可以通过局域网访问互联网，并允许虚拟机之间直接通信。
内部网络模式
- 内部网络模式使得虚拟机可以创建一个完全隔离的网络，虚拟机之间可以直接通信，但无法访问互联网或外部网络。
仅主机网络模式
- 仅主机网络模式允许虚拟机之间可以通信，并且与主机之间也可以通信，但无法访问互联网或外部网络。

	VM <> VM	VM → HOST	HOST → VM	VM → Internet	Internet → VM
网络地址转换 NAT	×	√	×	√	×
NAT 网络	√	√	×	√	×
Bridged Adapter 桥接网卡	√	√	√	√	√

TUN/TAP 网络设备

TAP 属于 Linux 内核支持的一种虚拟化网络设备，还有 TUN 也属于这种设备，它们完全由软件模拟实现，TUN/TAP 负责在内核协议栈和用户进程之间传送协议数据单元。TUN 工作在网络层，而 TAP 工作在数据链路层，TUN 负责与应用程序交换 IP 数据包，而 TAP 与应用程序交换以太网帧。所以 TUN 经常涉及路由，而 TAP 常用于网络桥接。

SSH 远程登录虚拟机

宿主机任意下目录执行：

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): host2vm0_id_irsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in host2vm0_id_irsa.
Your public key has been saved in host2vm0_id_irsa.pub.
The key fingerprint is:
SHA256:OkWcw+R3x6Z2mzeYQuG033H3N9qIeym3TZKzz6YD8tQ user@ubuntu18
The key's randomart image is:
+---[RSA 2048]----+
|        .        |
|       = .   .   |
|        B .o. +  |
|       . oo.o+   |
|        S  ++ ..o|
|       o ..+.E=o=|
|      o   +..B+=+|
|       .   oo=@o+|
|           o=**= |
+----[SHA256]-----+

一直回车确定，生成公私钥，保存在~/.ssh目录下。

我在宿主机上生成的公私钥名称为，分别是host2vm0_id_rsa,host2vm0_id_rsa.pub方便我记忆。如果一直回车，那么生成的公私钥名称为id_rsa，id_rsa.pub。

将公钥复制到虚拟机 VM0 上，以当前虚拟机 VM0 的 IP：10.12.193.53 为例。

$ ssh-copy-id 10.12.193.53
# 输入密码
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
user@10.12.193.53's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '10.12.193.53'"
and check to make sure that only the key(s) you wanted were added.

然后就可以直接免密码登录了：

ssh user@10.12.193.53

Fixed Problems (Ongoing)

cannot ioctl tunsetiff tap0 device or resource busy (errno=16)

failed to initialize tap device: Operation not permitted

同类型错误：failed to create TAP device: Operation not permitted。因为创建虚拟设备 tap 需要 root 权限，所以需要使用 sudo 命令。执行 QEMU 启动是需要添加 sudo。

QEMU 虚拟机启动后网卡处于 DOWN 状态，无法获取 IP

查看是否是 MAC 地址配置错误，使用下面命令检查：

sudo ifconfig eth0 up
SIOCSIFFLAGS: Cannot assign requested address

如果报错，参考下面章节SIOCSIFFLAGS: Cannot assign requested address解决方法进行解决。

虚拟机可以 ping 通外网，宿主机无法 ping 外网

这种情况说明基本网络没有问题，只是 DNS 解析有问题，可以通过修改/etc/resolv.conf文件解决。

海宁 DNS 服务器地址：10.12.2.21 和 10.12.2.22，我的情况是只能 ping 10.12.2.21，可以选择自己能 ping 通的 DNS 服务器地址。如果无法 ping 通，说明问题不在这，需要自行解决。

# 修改 DNS 服务器地址
sudo vim /etc/resolv.conf
# 添加以下内容
nameserver 10.12.2.21
nameserver 10.12.2.22

网络配置错误，如何恢复配置之前的状态

最简单的方式 - 重启，因为所有操作都是命令行配置，都是临时配置，可以直接重启解决。

既然有这一小节，说明肯定有时候不方便直接重启，那么就需要手动恢复配置之前的状态。但是能够恢复的前提是需要记得之前的网卡 IP 地址、子网掩码、网关、广播地址等信息。这些信息在局域网里，可能只有 IP 不同，其他信息如果没记住可以查看其他同事的网卡配置即可。

# 将网桥绑定的网卡从网桥上移除
sudo brctl delif br0 enp2s0
sudo brctl delif br0 tap0
# 配置宿主机网卡信息，必须一字不差，保持和之前一模一样才能恢复
sudo ip addr add 10.12.192.173/20 broadcast 10.12.207.255 dev enp2s0
# 必须设置网关
sudo ip route add default via 10.12.192.1 dev enp2s0
# 重启网络管理器
systemctl restart NetworkManager

-netdev tap,id=tapnet,script=/qemu-script/qemu-ifup,:network script /qemu-script/qemu-ifup failed with status 256

可能原因 1: qemu-ifup 脚本没有执行权限，需要添加执行权限。

chmod +x qemu-ifup

可能原因 2: qemu-ifup 路径不对，必须放到/etc/qemu/目录下。

mkdir -p /etc/qemu
mv qemu-ifup /etc/qemu && mv qemu-ifdown /etc/qemu 
sudo chmod +x qemu-ifup
sudo chmod +x qemu-ifdown

SIOCSIFFLAGS: Cannot assign requested address

sudo ifconfig eth0 up
SIOCSIFFLAGS: Cannot assign requested address

一般由于 MAC 地址配置错误导致，可以通过修改 MAC 地址为多播地址解决。

sudo ifconfig enp2s0 hw ether 00:11:22:33:44:55

重启网卡

sudo ifconfig enp2s0 down
sudo ifconfig enp2s0 up

MAC 地址的第一个字节中的最后一位（即第 7 位）用于标识该地址是单播，多播还是广播地址。如果这个位设置为 0，则表示这是一个单播地址；如果设置为 1，则表示这是一个多播或广播地址。

使用这种方法，我们可以确定上述每个 MAC 地址是否是单播地址：

cd:c2:05:84:c8:2c - 单播地址
13:7b:49:fc:a6:aa - 单播地址
8f:aa:42:29:e8:68 - 单播地址

00:11:22:33:44:55 是多播地址。

qemu -device drive with 0 bus=0 unit=0 exists

这个错误通常意味着您尝试在 QEMU VM 中添加一个重复的设备。

如果您已经在 VM 中添加了驱动器，则可能会出现此问题。您可以检查是否存在两个具有相同 bus 和 unit 的设备（在此情况下，都是 0）。解决此问题的方法是删除重复设备或更改其配置以包括唯一的 bus 和 unit。

如果您没有意图添加重复的设备，在运行 QEMU 之前，您可能需要检查您的命令行，以确保正确设置了 -drive 选项。请注意，当使用 -device 添加设备时，您还应该避免使用 -drive 选项，因为它们可能引起冲突。

如果您需要进一步帮助，建议提供完整的 QEMU 命令和参数列表，以便更好地理解问题并提供更详细的建议。

参考资料

附录

QEMU启动RISC-V架构OpenEuler并配置OSC环境

Sun, 23 Jul 2023 19:28:29 +0000

基于Ubuntu 18.04，QEMU 8.0.2，OpenEuler 22.09

安装QEMU

安装基础编译工具

sudo apt install build-essential autoconf automake autotools-dev pkg-config bc curl \
                 gawk git bison flex texinfo gperf libtool patchutils mingw-w64 libmpc-dev \
                 libmpfr-dev libgmp-dev libexpat-dev libfdt-dev zlib1g-dev libglib2.0-dev \
                 libpixman-1-dev libncurses5-dev libncursesw5-dev meson libvirglrenderer-dev libsdl2-dev  -y

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt install python3.8 python3-pip  -y
sudo apt install -f
pip3 install meson

下载QEMU

建立文件夹用于编译：

cd && mkdir -p qemu-build

建立文件夹用于安装：

cd && mkdir -p /home/user/program/riscv64-qemu

可登录官网将版本号换成最新版本即可：

cd qemu-build && wget  "https://download.qemu.org/qemu-8.0.2.tar.xz"

tar -xf qemu-8.0.2.tar.xz --strip-components=1

安装QEMU

cd qemu-build && ./configure --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-linux-user,riscv64-softmmu \
               --enable-kvm --enable-sdl \
               --prefix=/home/user/program/riscv64-qemu

make install -j $(nproc)

配置环境变量

echo 'export QEMU_HOME=/home/user/program/riscv64-qemu' >> ~/.bashrc && echo 'export PATH=$QEMU_HOME/bin:$PATH' >> ~/.bashrc

source ~/.bashrc

下载 OpenEuler RISC-V 系统镜像

建立目录：

cd && mkdir -p /home/user/openeuler

根据自己的用户名修改user

下载OpenEuler 22.09版本，下载目录下所有文件/home/user/openeuler。如需下载其他版本请进入其他目录选择下载即可。

也可以根据自己的情况进入镜像站列表选择下载速度更快的镜像站下载

最新的23.03版本需要在中科院镜像站下载

文件说明：

fw_payload_oe_qemuvirt.elf: 利用 openSBI 将 kernel-5.10 的 image 作为 payload 所制作的 QEMU 启动所需文件
openEuler-22.09-qemu-xfce.qcow2.tar.zst: openEuler RISC-V QEMU GUI 镜像压缩包
preview_start_vm_xfce.sh: GUI 虚拟机启动脚本
openeuler-22.09-qemu.qcow2.tar.zst: openEuler RISC-V QEMU headless 镜像压缩包
preview_start_vm.sh: headless 虚拟机启动脚本

解压：

 sudo apt-get install zstd

 tar -I 'zstdmt' -xvf openEuler-22.09-riscv64-qemu.qcow2.tar.zst

执行启动脚本

chmod +x preview_start_vm.sh

bash preview_start_vm.sh

登录系统

用户名: root
默认密码: openEuler12#$

openEuler 22.09
Kernel 5.10.0 on an riscv64

4penEuler-riscv6
 login: openEuler 22.09
Kernel 5.10.0 on an riscv64

openEuler-riscv64 login: root
Password: 


Welcome to 5.10.0

System information as of time:   Mon Jul  3 07:52:19 PM CST 2023

System load:   0.17
Processes:   117
Memory used:   .6%
Swap used:   0.0%
Usage On:   6%
Users online:   1


[root@openEuler-riscv64 ~]# ls
[root@openEuler-riscv64 ~]# pwd

远程登录系统

ssh -p 12055 root@localhost

配置系统

以下操作均在root用户下执行，如果切换了用户会有提示。因为系统初始状态没有普通用户，也没有sudo，所以需要使用root完成一些基础配置。

修改root密码

原密码太复杂，修改简单密码

passwd root
# 输入两次密码

添加普通用户

# 添加用户 user
useradd -s /bin/bash -d /home/user -m user

passwd user
# 输入两次密码

# 添加管理员权限
usermod -aG wheel user

修改时间

echo "NTP=ntp.aliyun.com" >> /etc/systemd/timesyncd.conf

systemctl restart systemd-timesyncd.service

查看timesyncd运行状态：

systemctl status systemd-timesyncd.service

date命令可查看当前系统时间。验证是否配置成功。

时间务必正确设置，错误的时间会影响诸如https的TLS认证等过程。

配置DNS

vim /etc/resolv.conf
nameserver 119.29.29.29

配置软件包源

配置文件为 /etc/yum.repos.d/openEuler.repo 下

mv /etc/yum.repos.d/openEuler.repo  /etc/yum.repos.d/openEuler.repo.bk && sudo bash -c "cat << EOF > /etc/yum.repos.d/openEuler.repo
# just for test
[mainline]
name=mainline
baseurl=https://mirror.iscas.ac.cn/openeuler-sig-riscv/openEuler-RISC-V/preview/openEuler-22.09-V1-riscv64/repo/22.09/
enabled=1
gpgcheck=0
# just for test
[epol]
name=epol
baseurl=https://mirror.iscas.ac.cn/openeuler-sig-riscv/openEuler-RISC-V/preview/openEuler-22.09-V1-riscv64/repo/22.09/
enabled=1
gpgcheck=0
[extra]
name=extra
baseurl=https://mirror.iscas.ac.cn/openeuler-sig-riscv/openEuler-RISC-V/preview/openEuler-22.09-V1-riscv64/repo/extra/
enabled=1
gpgcheck=0
EOF"

需要注意的是，因为OpenEuler还在快速发展中，镜像地址可能会发生变化，所以需确认地址是否能够正常访问，如无法访问会导致404错误

[repoid]中的repoid为软件仓库（repository）的ID号，所有.repo配置文件中的各repoid不能重复，必须唯一。示例中repoid设置为base。 name为软件仓库描述的字符串。 baseurl为软件仓库的地址。 enabled为是否启用该软件源仓库，可选值为1和0。默认值为1，表示启用该软件源仓库。 gpgcheck可设置为1或0，1表示进行gpg（GNU Private Guard）校验，0表示不进行gpg校验，gpgcheck可以确定rpm包的来源是有效和安全的。 gpgkey为验证签名用的公钥。

磁盘扩容

在宿主机上安装 qemu-img 工具:

apt install qemu-utils

在 openEuler RISC-V 虚拟机上安装 growpart 工具:

dnf install cloud-utils-growpart

关闭QEMU虚拟机
把 qcow2 文件的容量加200GB：

$ qemu-img resize *.qcow2 +200G
Image resized.
$ qemu-img info *.qcow2
image: openEuler-preview.riscv64.qcow2
file format: qcow2
virtual size: 220 GiB 
disk size: 9.58 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false

QEMU 启动 openEuler RISC-V。

启动以后，我们先看看分区情况：可以看到根目录对应的分区只使用了 10G。

[root@openEuler-RISCV-rare ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    254:0    0  220G  0 disk
└─vda1 254:1    0   10G  0 part /

扩展分区 vda1，执行

growpart /dev/vda1

执行 lsblk 可以看到 / 所在的 vda1 分区已经扩展到了预期大小

[root@openEuler-RISCV-rare ~]# growpart /dev/vda 1
CHANGED: partition=1 start=2048 old: size=20969472 end=20971520 new: size=419428319 end=419430367
[root@openEuler-RISCV-rare ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    254:0    0  220G  0 disk
└─vda1 254:1    0  220G  0 part /

扩展文件系统：

resize2fs /dev/vda1

BUG

network backend ‘user‘ is not compiled into this binary

git clone https://gitlab.freedesktop.org/slirp/libslirp.git

http://security.ubuntu.com/ubuntu/pool/main/libs/libslirp/libslirp-dev_4.1.0-2ubuntu2.2_amd64.deb

sudo apt-get install libslirp-dev

重新编译QEMU：

cd qemu-build && rm -rf build

cd qemu-build && ./configure --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-linux-user,riscv64-softmmu \
               --enable-kvm --enable-sdl --enable-slirp\
               --prefix=/home/user/program/riscv64-qemu

make install -j $(nproc)

参考文档

RISC-V/doc/tutorials/vm-qemu-oErv.md at master · openeuler-mirror/RISC-V · GitHub

openEuler 22.09技术白皮书

QEMU's instance_init() vs. realize()

Tue, 01 Nov 2022 09:51:28 +0000

转载自huth (Thomas Huth)的一篇文章，原文已经 404，从网页快照中找回的文章。

Note that this is a blog post for (new) QEMU developers. If you are just interested in using QEMU, you can certainly skip this text. Otherwise, in case you have ever been in touch with the QEMU device model (“qdev”), you are likely aware of the basic qdev code boilerplate already:

static void mydev_realize(DeviceState *dev, Error **errp)
{
    
}

static void mydev_instance_init(Object *obj)
{
    
}

static Property mydev_properties[] = {
    DEFINE_PROP_xxx("myprop", MyDevState, field, ...),
    
    DEFINE_PROP_END_OF_LIST(),
};

static void mydev_class_init(ObjectClass *oc, void *data)
{
    DeviceClass *dc = DEVICE_CLASS(oc);

    dc->realize = mydev_realize;
    dc->desc = "My cool device";
    dc->props = mydev_properties;
    
}

static const TypeInfo mydev_info = {
    .name          = TYPE_MYDEV,
    .parent        = TYPE_SYS_BUS_DEVICE,  
    .instance_size = sizeof(mydev_state),
    .instance_init = mydev_instance_init,
    .class_init    = mydev_class_init,
};

static void mydev_register_types(void)
{
    type_register_static(&mydev_info);
}

type_init(mydev_register_types)

There are three different initialization functions involved here, the class_init, the instance_init and the realize function. While it is quite obvious to distinguish the class_init function from the two others (it is used for initializing the class data, not the data that is used for an instance … this is similar to the object model with classes and instances in C++), I initially always wondered about the difference between the instance_init() and the realize() functions. Having fixed quite a lot of related bugs in the past months in the QEMU code base, I now know that a lot of other people are also not properly aware of the difference here, so I think it is now time to write down some information that I’m now aware of, to make sure that I don’t forget about this again, and maybe help others to avoid related bugs in the future ;-)

First it is of course always a good idea to have a look at the documentation. While the documentation of TypeInfo (where instance_init() is defined) is not very helpful to understand the differences, the documentation of DeviceClass (where realize() is defined) has some more useful information: You can learn here that the object instantiation is done first, before the device is realized, i.e. the instance_init() function is called first, and the realize() function is called afterwards. The former must not fail, while the latter can return an error to its caller via a pointer to an “Error” object pointer.

So the basic idea here is that device objects are first instantiated, then these objects can be inspected for their interfaces and their creators can set up their properties to configure their settings and wire them up with other devices, before the device finally becomes “active” by being realized. It is important here to notice that devices can be instantiated (and also finalized) without being realized! This happens for example if the device is introspected: If you enter for example device_add xyz,help at the HMP monitor, or if you send the device-list-properties QOM command to QEMU to retrieve the device’s properties, QEMU creates a temporary instance of the device to query the properties of the object, without realizing it. The object gets destroyed (“finalized”) immediately afterwards.

Knowing this, you can avoid a set of bugs which could be found with a couple of devices in the past:

If you want your device to provide properties for other parts of the QEMU code or for the users, and you want to add those properties via one of the many object_property_add*() functions of QEMU (instead of using the “props” field of the DeviceClass), then you should do this in the instance_init() and not in the realize() function. Otherwise the properties won’t show up when the user runs --device xyz,help or the device-list-properties QOM command to get some information about your device.
instance_init() functions must really never fail, i.e. also not call abort() or exit(). Otherwise QEMU can terminate unexpectedly when a user simply wanted to have a look at the list of device properties with device_add xyz,help or the device-list-properties QOM command. If your device cannot work in certain circumstances, check for the error condition in the realize() function instead and return with an appropriate error there.
Never assume that your device is always instantiated only with the machine that it was designed for. It’s of course a good idea to set the “user_creatable = false” flag in the DeviceClass of your device if your device cannot be plugged in arbitrary machines. But device introspection can still happen at any time, with any machine. So if you wrote a device called “mydev-a” that only works with --machine A, the user still can start QEMU with the option --machine B instead and then run device_add mydev-a,help or the device-list-properties QOM command. The instance_init() function of your device will be called to create a temporary instance of your device, even though the base machine is B and not A here. So you especially should take care to not depend on the availability of certain buses or other devices in the instance_init() function, nor use things like serial_hd() or nd_table[] in your instance_init() function, since these might (and should) have been used by the machine init function already. If your device needs to be wired up, provide properties as interfaces to the outside and let the creator of your device (e.g. the machine init code) wire your device between the device instantiation and the realize phase instead.
Make sure that your device leaves a clean state after a temporary instance is destroyed again, i.e. don’t assume that there will be only one instance of your device which is created at the beginning right after QEMU has been started and is destroyed at the very end before QEMU terminates. Thus do not assume that the things that you do in your instance_init() don’t need explicit clean-up since the device instance will only be destroyed when QEMU terminates. Device instances can be created and destroyed at any time, so when the device is finalized, you must not leave any dangling pointers or references to your device behind you, e.g. in the QOM tree. When you create other objects in your instance_init() function, make sure to set proper parents of these objects or use an instance_finalize() function, so that the created objects get cleaned up correctly again when your device is destroyed.

All in all, if you write code for a new QEMU device, it is likely a good idea to use the instance_init() function only for e.g. creating properties and other things that are required before device realization, and then do the main work in the realize() function instead.

QEMU 源码分析-QOM

Wed, 09 Mar 2022 16:02:19 +0000

QOM 简介

QOM(QEMU Object Model) 是 QEMU 的一个模块，用于描述虚拟机的结构，包括虚拟机的 CPU、内存、硬盘、网络、输入输出设备等。QEMU 为了方便整个系统的构建，实现了自己的一套的面向对象机制，也就是 QOM(QEMU Object Model)。它能够方便的表示各个设备（Device）与总线（Bus）之间的关系。

这个模型主要包含四个结构体：

Object: 是所有对象的基类 Base Object
ObjectClass: 是所有类对象的基类
TypeInfo：是用户用来定义一个 Type 的工具型的数据结构
TypeImpl：TypeInfo 抽象数据结构，TypeInfo 的属性与 TypeImpl 的属性对应

在 QEMU 里要初始化一个对象需要完成四步：

将 TypeInfo 注册 TypeImpl
实例化 Class（ObjectClass）
实例化 Object
添加 Property

Responsive Image

QOM 中的面向对象

继承

在 QEMU 中通过 TypeInfo 来定义一个类。

例如 x86_base_cpu_type_info 就是一个 class，

static const TypeInfo x86_base_cpu_type_info = {
        .name = X86_CPU_TYPE_NAME("base"),
        .parent = TYPE_X86_CPU,
        .class_init = x86_cpu_base_class_init,
};

利用结构体包含来实现继承。这应该是所有的语言实现继承的方法，在 C++ 中，结构体包含的操作被语言内部实现了，而 C 语言需要自己实现。

例如 x86_cpu_type_info 的 parent 是 cpu_type_info, 他们的结构体分别是 X86CPU 和 CPUState。

static const TypeInfo x86_cpu_type_info = {
    .name = TYPE_X86_CPU,
    .parent = TYPE_CPU,
  // ...
    .instance_size = sizeof(X86CPU),
};

static const TypeInfo cpu_type_info = {
    .name = TYPE_CPU,
    .parent = TYPE_DEVICE,
  // ...
    .instance_size = sizeof(CPUState),
};

在 X86CPU 中包含一个 CPUState。

struct X86CPU {
    /*< private >*/
    CPUState parent_obj;
    /*< public >*/

    CPUNegativeOffsetState neg;

静态成员

静态成员变量可以在类的多个对象中访问，但是要在类外声明。不同对象访问的其实是同一个实体，静态成员变量被多个对象共享。

static const TypeInfo x86_cpu_type_info = {
    .name = TYPE_X86_CPU,
    .parent = TYPE_CPU,
    .instance_size = sizeof(X86CPU),
    .instance_init = x86_cpu_initfn,
    .instance_post_init = x86_cpu_post_initfn,

    .abstract = true,
    .class_size = sizeof(X86CPUClass),
    .class_init = x86_cpu_common_class_init,
};

其中 X86CPU 描述的是非静态成员，而 X86CPUClass 描述的是静态的成员。也就是说class_init初始化静态成员，instance_init初始化非静态成员。

那么何时初始化静态成员呢？首先得告诉系统，咱有class_init这个初始化函数，等需要的时候随时可以调用它初始化，所有先解决如何将这个初始化函数注册到系统中？

在target/i386/cpu.c最后使用了type_init。在qemu/include/qemu/module.h中有一个type_init宏定义，除了type_init还有其他宏，比如block_init，opts_init等。每个宏都表示一类module，通过module_init构造出来。我们展开这个宏，

static void __attribute__((constructor))
do_qemu_init_x86_cpu_register_types(void) {
  register_module_init(x86_cpu_register_types, MODULE_INIT_QOM);
}

通过 gcc 扩展属性__attribute__((constructor))可以让 do_qemu_init_x86_cpu_register_types 在运行 main 函数之前运行。 register_module_init 会让 x86_cpu_register_types 这个函数挂载到 init_type_list[MODULE_INIT_QOM] 这个链表上。

Responsive Image

到底，所有的 TypeInfo 通过 type_init 都被放到 type_table 上了，之后通过 Typeinfo 的名称调用 type_table_lookup 获取到 TypeImpl 了。

到这里，将TYPE_X86_CPU注册进类系统，包括其初始化函数，这部分也就是 QEMU 中类型的构造。那么何时调用静态成员初始化函数呢？也就是类型的初始化。

静态成员是所有的对象公用的，其初始化显然要发生在所有的对象初始化之前。

main
    qemu_init 
        select_machine 
            object_class_get_list 
                object_class_foreach 
                    g_hash_table_foreach 
                        object_class_foreach_tramp 
                            type_initialize 
                                type_initialize 
                                    x86_cpu_common_class_init

select_machine 需要获取所有的 TYPE_MACHINE 的 class, 其首先会调用所有的class_list，其会遍历 type_table，遍历的过程中会顺带 type_initialize 所有的 TypeImpl 进而调用的 class_init。

说完类型的初始化，再讲一下对象的初始化，也就是初始化非静态成员，也就是instance_init在何时被调用？

对象初始化，通过调用 object_new 来实现初始化。

object_initialize_with_type
- 初始化一个空的 :Object::properties
- object_init_with_type
  - 如果 object 有 parent，那么调用 object_init_with_type 首先初始化 parent 的
  - 调用TypeImpl::instance_init

main 
    qemu_init 
        qmp_x_exit_preconfig 
            qemu_init_board 
                machine_run_board_init 
                    pc_init_v6_1 
                        pc_init1 
                            x86_cpus_init 
                                x86_cpu_new 
                                    object_new 
                                        object_new_with_type 
                                            object_initialize_with_type 
                                                object_init_with_type 
                                                    x86_cpu_initfn

多态

多态是指同一操作作用于不同的对象，可以有不同的解释，产生不同的执行结果。为了实现多态，QOM 实现了一个非常重要的功能，就是动态类型转换。我们可以使用相关的函数，将一个Object的指针在运行时转换为子类对象的指针，可以将一个ObjectClass的指针在运行时转换为子类的指针。这样就可以调用子类中定义的函数指针来完成相应的功能。

QEMU 定义了一些列的宏封来进行动态类型转换：

//include/qom/object.h

/**
 * DECLARE_INSTANCE_CHECKER:
 * @InstanceType: instance struct name
 * @OBJ_NAME: the object name in uppercase with underscore separators
 * @TYPENAME: type name
 *
 * Direct usage of this macro should be avoided, and the complete
 * OBJECT_DECLARE_TYPE macro is recommended instead.
 *
 * This macro will provide the instance type cast functions for a
 * QOM type.
 */
#define DECLARE_INSTANCE_CHECKER(InstanceType, OBJ_NAME, TYPENAME) \
    static inline G_GNUC_UNUSED InstanceType * \
    OBJ_NAME(const void *obj) \
    { return OBJECT_CHECK(InstanceType, obj, TYPENAME); }

/**
 * DECLARE_CLASS_CHECKERS:
 * @ClassType: class struct name
 * @OBJ_NAME: the object name in uppercase with underscore separators
 * @TYPENAME: type name
 *
 * Direct usage of this macro should be avoided, and the complete
 * OBJECT_DECLARE_TYPE macro is recommended instead.
 *
 * This macro will provide the class type cast functions for a
 * QOM type.
 */
#define DECLARE_CLASS_CHECKERS(ClassType, OBJ_NAME, TYPENAME) \
    static inline G_GNUC_UNUSED ClassType * \
    OBJ_NAME##_GET_CLASS(const void *obj) \
    { return OBJECT_GET_CLASS(ClassType, obj, TYPENAME); } \
    \
    static inline G_GNUC_UNUSED ClassType * \
    OBJ_NAME##_CLASS(const void *klass) \
    { return OBJECT_CLASS_CHECK(ClassType, klass, TYPENAME); }

/**
 * DECLARE_OBJ_CHECKERS:
 * @InstanceType: instance struct name
 * @ClassType: class struct name
 * @OBJ_NAME: the object name in uppercase with underscore separators
 * @TYPENAME: type name
 *
 * Direct usage of this macro should be avoided, and the complete
 * OBJECT_DECLARE_TYPE macro is recommended instead.
 *
 * This macro will provide the three standard type cast functions for a
 * QOM type.
 */
#define DECLARE_OBJ_CHECKERS(InstanceType, ClassType, OBJ_NAME, TYPENAME) \
    DECLARE_INSTANCE_CHECKER(InstanceType, OBJ_NAME, TYPENAME) \
    \
    DECLARE_CLASS_CHECKERS(ClassType, OBJ_NAME, TYPENAME)

/**
 * OBJECT_DECLARE_TYPE:
 * @InstanceType: instance struct name
 * @ClassType: class struct name
 * @MODULE_OBJ_NAME: the object name in uppercase with underscore separators
 *
 * This macro is typically used in a header file, and will:
 *
 *   - create the typedefs for the object and class structs
 *   - register the type for use with g_autoptr
 *   - provide three standard type cast functions
 *
 * The object struct and class struct need to be declared manually.
 */
#define OBJECT_DECLARE_TYPE(InstanceType, ClassType, MODULE_OBJ_NAME) \
    typedef struct InstanceType InstanceType; \
    typedef struct ClassType ClassType; \
    \
    G_DEFINE_AUTOPTR_CLEANUP_FUNC(InstanceType, object_unref) \
    \
    DECLARE_OBJ_CHECKERS(InstanceType, ClassType, \
                         MODULE_OBJ_NAME, TYPE_##MODULE_OBJ_NAME)

/**
 * OBJECT:
 * @obj: A derivative of #Object
 *
 * Converts an object to a #Object.  Since all objects are #Objects,
 * this function will always succeed.
 */
#define OBJECT(obj) \
    ((Object *)(obj))

/**
 * OBJECT_CLASS:
 * @class: A derivative of #ObjectClass.
 *
 * Converts a class to an #ObjectClass.  Since all objects are #Objects,
 * this function will always succeed.
 */
#define OBJECT_CLASS(class) \
    ((ObjectClass *)(class))

/**
 * OBJECT_CHECK:
 * @type: The C type to use for the return value.
 * @obj: A derivative of @type to cast.
 * @name: The QOM typename of @type
 *
 * A type safe version of @object_dynamic_cast_assert.  Typically each class
 * will define a macro based on this type to perform type safe dynamic_casts to
 * this object type.
 *
 * If an invalid object is passed to this function, a run time assert will be
 * generated.
 */
#define OBJECT_CHECK(type, obj, name) \
    ((type *)object_dynamic_cast_assert(OBJECT(obj), (name), \
                                        __FILE__, __LINE__, __func__))

/**
 * OBJECT_CLASS_CHECK:
 * @class_type: The C type to use for the return value.
 * @class: A derivative class of @class_type to cast.
 * @name: the QOM typename of @class_type.
 *
 * A type safe version of @object_class_dynamic_cast_assert.  This macro is
 * typically wrapped by each type to perform type safe casts of a class to a
 * specific class type.
 */
#define OBJECT_CLASS_CHECK(class_type, class, name) \
    ((class_type *)object_class_dynamic_cast_assert(OBJECT_CLASS(class), (name), \
                                               __FILE__, __LINE__, __func__))

/**
 * OBJECT_GET_CLASS:
 * @class: The C type to use for the return value.
 * @obj: The object to obtain the class for.
 * @name: The QOM typename of @obj.
 *
 * This function will return a specific class for a given object.  Its generally
 * used by each type to provide a type safe macro to get a specific class type
 * from an object.
 */
#define OBJECT_GET_CLASS(class, obj, name) \
    OBJECT_CLASS_CHECK(class, object_get_class(OBJECT(obj)), name)

以OBJECT_DECLARE_TYPE(X86CPU, X86CPUClass, X86_CPU)为例，宏展开如下：

typedef struct X86CPU X86CPU;
typedef struct X86CPUClass X86CPUClass;
G_DEFINE_AUTOPTR_CLEANUP_FUNC(X86CPU, object_unref)
static inline G_GNUC_UNUSED X86CPU *X86_CPU(const void *obj) {
  return ((X86CPU *)object_dynamic_cast_assert(
      ((Object *)(obj)), (TYPE_X86_CPU),
      "~/core/vn/docs/qemu/res/qom-macros.c", 64, __func__));
}
static inline G_GNUC_UNUSED X86CPUClass *X86_CPU_GET_CLASS(const void *obj) {
  return ((X86CPUClass *)object_class_dynamic_cast_assert(
      ((ObjectClass *)(object_get_class(((Object *)(obj))))), (TYPE_X86_CPU),
      "~/core/vn/docs/qemu/res/qom-macros.c", 64, __func__));
}
static inline G_GNUC_UNUSED X86CPUClass *X86_CPU_CLASS(const void *klass) {
  return ((X86CPUClass *)object_class_dynamic_cast_assert(
      ((ObjectClass *)(klass)), (TYPE_X86_CPU),
      "~/core/vn/docs/qemu/res/qom-macros.c", 64, __func__));
}

OBJECT_DECLARE_TYPE通常在头文件中使用，效果是：

创建了X86CPU和X86CPUClass的typedef
用G_DEFINE_AUTOPTR_CLEANUP_FUNC注册类型
创建了三个类型转换函数
- X86_CPU : 将任何一个 object 指针转换为 X86CPU（Object 转子对象）
- X86_CPU_GET_CLASS : 根据 object 指针获取到 X86CPUClass
- X86_CPU_CLASS : 根据 ObjectClass 指针转换到 X86CPUClass（基类转子类）

这里的转换依赖内存布局，子类型的第一个成员总是基类型。子类转基类就很容易，只需要强制类型转换就可以实现。

参考

QEMU 中的面向对象 : QOM | Deep Dark Fantasy 浅谈 QEMU 的对象系统 - 简书

QEMU 源码分析-内存虚拟化

Tue, 25 Jan 2022 13:42:11 +0000

1.大部分转载自QEMU 内存虚拟化源码分析 | Keep Coding | 苏易北 2.原文源码为 QEMU1.2.0，版本较旧，部分源码内容根据 QEMU6.2 版本修改 3.部分内容根据自己理解补充添加

概述

我们知道操作系统给每个进程分配虚拟内存，通过页表映射，变成物理内存进行访问。当有了虚拟机之后，情况会变得更加复杂。因为虚拟机对于物理机来讲是一个进程，但是虚拟机里面也有内核，也有虚拟机里面跑的进程。所以有了虚拟机，内存就变成了四类：

虚拟机里面的虚拟内存（Guest OS Virtual Memory，GVA），这是虚拟机里面的进程看到的内存空间；
虚拟机里面的物理内存（Guest OS Physical Memory，GPA），这是虚拟机里面的操作系统看到的内存，它认为这是物理内存；
物理机的虚拟内存（Host Virtual Memory，HVA），这是物理机上的 qemu 进程看到的内存空间；
物理机的物理内存（Host Physical Memory，HPA），这是物理机上的操作系统看到的内存。

内存虚拟化的关键在于维护 GPA 到 HVA 的映射关系。

页面分配和映射的两种方式

要搞清楚 QEMU system emulation 的仿真架构，首先对于 Host OS，将 QEMU 作为进程启动，然后对于 QEMU 进程，会仿真各种硬件和运行 Guest OS，在这层 OS 上运行要全系统模拟的应用程序，因此对于 Guest OS 管理的内存要实现到 QEMU 进程的虚拟空间的转换需要 softMMU（即需要对 GPA 到 HVA 进行转换）。从 GVA 到 GPA 到 HVA 到 HPA，性能很差，为了解决这个问题，有两种主要的思路。

影子页表 Shadow Page Table，SPT

第一种方式就是软件的方式，影子页表（Shadow Page Table）。

KVM 通过维护记录 GVA->HPA 的影子页表 SPT，减少了地址转换带来的开销，可以直接将 GVA 转换为 HPA。

内存映射要通过页表来管理，页表地址应该放在 CR3 寄存器里面。在软件虚拟化的内存转换中，GVA 到 GPA 的转换通过查询 CR3 寄存器来完成，CR3 中保存了 Guest 的页表基地址，然后载入 MMU 中进行地址转换。

在加入了 SPT 技术后，当 Guest 访问 CR3 时，KVM 会捕获到这个操作 EXIT_REASON_CR_ACCESS，之后 KVM 会载入特殊的 CR3 和影子页表，欺骗 Guest 这就是真实的 CR3。之后就和传统的访问内存方式一致，当需要访问物理内存的时候，只会经过一层影子页表的转换。

本来的过程是，客户机要通过 cr3 找到客户机的页表，实现从 GVA 到 GPA 的转换，然后在宿主机上，要通过 cr3 找到宿主机的页表，实现从 HVA 到 HPA 的转换。为了实现客户机虚拟地址空间到宿主机物理地址空间的直接映射。客户机中每个进程都有自己的虚拟地址空间，所以 KVM 需要为客户机中的每个进程页表都要维护一套相应的影子页表。在客户机访问内存时，使用的不是客户机的原来的页表，而是这个页表对应的影子页表，从而实现了从客户机虚拟地址到宿主机物理地址的直接转换。而且，在 TLB 和 CPU 缓存上缓存的是来自影子页表中客户机虚拟地址和宿主机物理地址之间的映射，也因此提高了缓存的效率。

Responsive Image

为了快速检索 Guest 页表对应的影子页表，KVM 为每个客户机维护了一个 hash 表来进行客户机页表到影子页表之间的映射。对于每一个 Guest 来说，其页目录和页表都有唯一的 GPA，通过页目录/页表的 GPA 就可以在哈希链表中快速地找到对应的影子页目录/页表。

当 Guest 切换进程时，Guest 会把待切换进程的页表基址载入 CR3，而 KVM 将会截获这一特权指令。KVM 在哈希表中找到与此页表基址对应的影子页表基址，载入 Guest CR3，使 Guest 在恢复运行时 CR3 实际指向的是新切换进程对应的影子页表。

影子页表的引入，减少了 GVA->HPA 的转换开销，但是缺点在于需要为 Guest 的每个进程都维护一个影子页表，这将带来很大的内存开销。同时影子页表的建立是很耗时的，如果 Guest 的进程过多，将导致影子页表频繁切换。

因此 Intel 和 AMD 在此基础上提供了基于硬件的虚拟化技术 EPT。

扩展页表 Extent Page Table，EPT

Intel 的 EPT（Extent Page Table）技术和 AMD 的 NPT（Nest Page Table）技术都对内存虚拟化提供了硬件支持。这两种技术原理类似，都是在硬件层面上实现 GVA 到 HPA 之间的转换。下面就以 EPT 为例分析一下 KVM 基于硬件辅助的内存虚拟化实现。

EPT 在原有客户机页表对客户机虚拟地址 GVA 到客户机物理地址 GPA 映射的基础上，又引入了 EPT 页表来实现客户机物理地址 GPA 到宿主机物理地址 HPA 的另一次映射。客户机运行时，客户机页表被载入 CR3，而 EPT 页表被载入专门的 EPT 页表指针寄存器 EPTP。

即 EPT 技术采用了在两级页表结构，即原有 Guest OS 页表对 GVA->GPA 映射的基础上，又引入了 EPT 页表来实现 GPA->HPA 的另一次映射，这两次地址映射都是由硬件自动完成。

有了 EPT，在GPA->HPA转换的过程中，缺页会产生 EPT 缺页异常。KVM 首先根据引起异常的客户机物理地址，映射到对应的宿主机虚拟地址，然后为此虚拟地址分配新的物理页，最后 KVM 再更新 EPT 页表，建立起引起异常的客户机物理地址到宿主机物理地址之间的映射。

KVM 只需为每个客户机维护一套 EPT 页表，也大大减少了内存的开销。

这里，我们重点看第二种方式。因为使用了 EPT 之后，客户机里面的页表映射，也即从 GVA 到 GPA 的转换，还是用传统的方式，和在内存管理那一章讲的没有什么区别。而 EPT 重点帮我们解决的就是从 GPA 到 HPA 的转换问题。因为要经过两次页表，所以 EPT 又 tdp(two dimentional paging)。

EPT 的页表结构也是分为四层，EPT Pointer（EPTP）指向 PML4 的首地址。

Responsive Image

QEMU 的主要工作

内存虚拟化的目的就是让虚拟机能够无缝的访问内存。有了 Intel EPT 的支持后，CPU 在 VMX non-root 状态时进行内存访问会再做一次 EPT 转换。在这个过程中，QEMU 会负责以下内容：

首先需要从自己的进程地址空间中申请内存用于 Guest 需要将上一步中申请到的内存的虚拟地址（HVA）和 Guest 的物理地址之间的映射关系传递给 KVM（kernel），即 GPA->HVA 需要组织一系列的数据结构来管理虚拟内存空间，并在内存拓扑结构更改时将最新的内存信息同步至 KVM 中

QEMU 和 KVM 的工作分界

QEMU 和 KVM 之间是通过 KVM 提供的 ioctl() 接口进行交互的。在内核的 kvm_vm_ioctl() 中，设置虚拟机内存的系统调用【kernel 就是一系列系统调用函数接口和处理逻辑，其中有个处理”创建/设置虚拟机内存“的系统调用接口】为 VM_SET_USER_MEMORY_REGION：

static long kvm_vm_ioctl(struct file *filp,
               unsigned int ioctl, unsigned long arg)
{
    /* ... */
    case KVM_SET_USER_MEMORY_REGION: { // 在 KVM 中注册用户空间传入的内存信息
        struct kvm_userspace_memory_region kvm_userspace_mem;

        r = -EFAULT;
         // 将传入的数据结构复制到内核空间
        if (copy_from_user(&kvm_userspace_mem, argp, sizeof kvm_userspace_mem))
            goto out;

         // 实际进行处理的函数
        r = kvm_vm_ioctl_set_memory_region(kvm, &kvm_userspace_mem, 1);
        if (r)
            goto out;
        break;
    }
    /* ... */
}

可以看到这里需要传递的参数类型为 kvm_userspace_memory_region：

/* for KVM_SET_USER_MEMORY_REGION */
struct kvm_userspace_memory_region {
    __u32 slot;            // slot 编号 [参考：https://www.cnblogs.com/LoyenWang/p/11922887.html]
    __u32 flags;           // 标志位，例如是否追踪脏页、是否可用等
    __u64 guest_phys_addr; // Guest 物理地址，即 GPA
    __u64 memory_size;     // 内存大小，单位 bytes
    __u64 userspace_addr;  // 从 QEMU 进程地址空间中分配内存的起始地址，即 HVA
};

KVM_SET_USER_MEMORY_REGION这个 ioctl 主要目的就是设置GPA->HVA的映射关系，KVM 会继续调用kvm_vm_ioctl_set_memory_region()，在内核空间维护并管理 Guest 的内存。

结构体名	说明
AddressSpace	VM 能看到的一段地址空间，偏向 Host 侧【注意指的是偏向】
MemoryRegion	地址空间中一段逻辑层面的内存区域，偏向 Guest 侧
RAMBlock	记录实际分配的内存地址信息，存储了 GPA->HVA 的映射关系
FlatView	MemoryRegion 对应的平面展开视图，包含一个 FlatRange 类型的 ranges 数组
FlatRange	对应一段虚拟机物理地址区间，各个 FlatRange 不会重叠，按照地址的顺序保存在数组中
MemoryRegionSection	表示 MemoryRegion 中的片段
MemoryListener	回调函数集合
KVMSlot	KVM 中内存管理的基本单位，表示一个内存插槽
kvm_userspace_memory_region	调用 ioctl(KVM_SET_USER_MEMORY_REGION) 时需要向 KVM 传递的参数

具体实现机制

QEMU 的内存申请流程大致可分为三个部分：回调函数的注册、AddressSpace 的初始化、实际内存的分配。下面将根据在 vl.c 的 main() 函数中的调用顺序分别介绍。

回调函数的注册

Responsive Image

int main()
  └─ static int configure_accelerator()
       └─ int kvm_init()                                     // 初始化 KVM
            ├─ int kvm_ioctl(KVM_CREATE_VM)                  // 创建 VM
            ├─ int kvm_arch_init()                           // 针对不同的架构进行初始化
            └─ void memory_listener_register()               // 注册 kvm_memory_listener
                 └─ static void listener_add_address_space() // 调用 region_add 回调
                      └─ static void kvm_region_add()        // region_add 对应的回调实现
                           └─ static void kvm_set_phys_mem() // 根据传入的 section 填充 KVMSlot
                                └─ static int kvm_set_user_memory_region()
                                     └─ int ioctl(KVM_SET_USER_MEMORY_REGION)

进入configure_accelerator()后，QEMU会先调用configure_accelerator()设置 KVM 的加速支持，之后进入kvm_init()。该函数主要完成对 KVM 的初始化，包括一些常规检查如 CPU 个数、KVM 版本等，之后通过kvm_ioctl(KVM_CREATE_VM)与内核交互，创建 KVM 虚拟机。在kvm_init()的最后，会调用memory_listener_register()注册kvm_memory_listener：

static int kvm_init(MachineState *ms)
{
    MachineClass *mc = MACHINE_GET_CLASS(ms);
    // 打开/dev/kvm
    s->fd = qemu_open_old("/dev/kvm", O_RDWR);
    // 创建 VM
    do {
        ret = kvm_ioctl(s, KVM_CREATE_VM, type);
    } while (ret == -EINTR);
/* ... */
    ret = kvm_arch_init(s); // 针对不同的架构进行初始化

    // 对于以下 AddressSpace，设置其对应的 listener
    kvm_memory_listener_register(s, &s->memory_listener,
                                 &address_space_memory, 0, "kvm-memory");
    memory_listener_register(&kvm_coalesced_pio_listener,
                             &address_space_io);
/* ... */
}

void memory_listener_register(MemoryListener *listener, AddressSpace *as)
{
    MemoryListener *other = NULL;

    /* Only one of them can be defined for a listener */
    assert(!(listener->log_sync && listener->log_sync_global));

    listener->address_space = as;
    if (QTAILQ_EMPTY(&memory_listeners)
        || listener->priority >= QTAILQ_LAST(&memory_listeners)->priority) {
        QTAILQ_INSERT_TAIL(&memory_listeners, listener, link);
    } else {
        QTAILQ_FOREACH(other, &memory_listeners, link) {
            if (listener->priority < other->priority) {
                break;
            }
        }
        QTAILQ_INSERT_BEFORE(other, listener, link);
    }

    if (QTAILQ_EMPTY(&as->listeners)
        || listener->priority >= QTAILQ_LAST(&as->listeners)->priority) {
        QTAILQ_INSERT_TAIL(&as->listeners, listener, link_as);
    } else {
        QTAILQ_FOREACH(other, &as->listeners, link_as) {
            if (listener->priority < other->priority) {
                break;
            }
        }
        QTAILQ_INSERT_BEFORE(other, listener, link_as);
    }

    listener_add_address_space(listener, as);
}

最后的listener_add_address_space()主要是将 listener 注册到其对应的 AddressSpace 上，并根据 AddressSpace 对应的 FlatRange 数组，生成 MemoryRegionSection【MemoryRegionSection就像是为FlatRange数组设置的一种中介表示，便于传入KVM，因为传入KVM应该是对平坦内存的一种表示】，并注册到 KVM 中：


static void listener_add_address_space(MemoryListener *listener,
                                       AddressSpace *as)
{
    FlatView *view;
    FlatRange *fr;

    if (listener->begin) {
        listener->begin(listener);
    }
    /* 开启内存脏页记录 */
    if (global_dirty_tracking) {
        if (listener->log_global_start) {
            listener->log_global_start(listener);
        }
    }

    /* 遍历 AddressSpace 对应的 FlatRange 数组，并将其转换成 MemoryRegionSection */
    view = address_space_get_flatview(as);
    FOR_EACH_FLAT_RANGE(fr, view) {
        MemoryRegionSection section = section_from_flat_range(fr, view);
        /* 将 section 所代表的内存区域注册到 KVM 中 */
        if (listener->region_add) {
            listener->region_add(listener, &section);
        }
        if (fr->dirty_log_mask && listener->log_start) {
            listener->log_start(listener, &section, 0, fr->dirty_log_mask);
        }
    }
    if (listener->commit) {
        listener->commit(listener);
    }
    flatview_unref(view);
}

由于此时 AddressSapce 尚未初始化，所以此处的循环为空，仅是在全局注册了kvm_memory_listener。最后调用了kvm_memory_listener->region_add()，对应的实现是kvm_region_add()，该函数最终会通过ioctl(KVM_SET_USER_MEMORY_REGION)，将 QEMU 侧申请的内存信息传入 KVM 进行注册，这里的流程会在下一部分进行分析。

AddressSpace 的初始化

Responsive Image

int main()
  └─ void cpu_exec_init_all()
       ├─ static void memory_map_init()
       |    ├─ void memory_region_init()    // 初始化 system_memory/io 这两个全局 MemoryRegion
       |    ├─ void set_system_memory_map() // address_space_memory->root = system_memory
       |    |    └─ static void memory_region_update_topology()        // 为 MemoryRegion 生成 FlatView
       |    |         └─ static void address_space_update_topology()   // as->current_map = new_view
       |    |              └─ static void address_space_update_topology_pass()
       |    |                   └─ static void kvm_region_add()        // region_add 对应的回调实现
       |    |                        └─ static void kvm_set_phys_mem() // 根据传入的 section 填充 KVMSlot
       |    |                             └─ static int kvm_set_user_memory_region()
       |    |                                  └─ int ioctl(KVM_SET_USER_MEMORY_REGION)
       |    |
       |    └─ void memory_listener_register() // 注册对应的 MemoryListener
       |         └─ static void listener_add_address_space()
       |
       └─ static void io_mem_init()
            └─ void memory_region_init_io() // ram/rom/unassigned/notdirty/subpage-ram/watch
                 └─ void memory_region_init()

第一部分在全局注册了kvm_memory_listener，但由于AddressSpace 尚未初始化，实际上并未向 KVM 中注册任何实际的内存信息。QEMU 在main()函数中会继续调用cpu_exec_init_all()对AddressSpace进行初始化，该函数实际上是对两个 init 函数的封装调用：


void cpu_exec_init_all(void)
{
    qemu_mutex_init(&ram_list.mutex);
    /* The data structures we set up here depend on knowing the page size,
     * so no more changes can be made after this point.
     * In an ideal world, nothing we did before we had finished the
     * machine setup would care about the target page size, and we could
     * do this much later, rather than requiring board models to state
     * up front what their requirements are.
     */
    finalize_target_page_bits();
    io_mem_init();      // 初始化六个I/O MemoryRegion
    memory_map_init(); // 初始化两个全局 AddressSpace，以及对应的 MemoryRegion、FlatView
    qemu_mutex_init(&map_client_list_lock);
}

先来看memory_map_init()，主要用来初始化两个全局的系统地址空间system_memory、system_io

static void memory_map_init(void)
{
    system_memory = g_malloc(sizeof(*system_memory));
    // 1. 初始化 system_memory
    memory_region_init(system_memory, NULL, "system", UINT64_MAX);
    // 2. 设置 address_space_memory 关联 system_memory
    // 这两个都是全局变量，也就是把内存地址空间和 IO 地址空间于对应的 MemoryRegion 联系起来 
    //及其对应的 FlatView
    address_space_init(&address_space_memory, system_memory, "memory");

    system_io = g_malloc(sizeof(*system_io));
    // 1. 初始化 system_io  
    memory_region_init_io(system_io, NULL, &unassigned_io_ops, NULL, "io",
                          65536);
    // 2. 设置 address_space_io 关联 system_io 
    // 及其对应的 FlatView
    address_space_init(&address_space_io, system_io, "I/O");
}

这里比较重要的是address_space_init()，先设置 AddressSpace 对应的 MemoryRegion，之后根据system_memory更新address_space_memory对应的 FlatView：

void address_space_init(AddressSpace *as, MemoryRegion *root, const char *name)
{
    memory_region_ref(root);
    // 将 address_space_memory 的 root 域指向 system_memory
    as->root = root;        
    as->current_map = NULL;
    as->ioeventfd_nb = 0;
    as->ioeventfds = NULL;
    QTAILQ_INIT(&as->listeners);
    QTAILQ_INSERT_TAIL(&address_spaces, as, address_spaces_link);
    as->name = g_strdup(name ? name : "anonymous");
    // 根据 system_memory 更新 address_space_memory 对应的 FlatView
    address_space_update_topology(as);  
    address_space_update_ioeventfds(as);
}

address_space_update_topology()会继续调用generate_memory_topology()生成 AddressSpace 对应的 FlatView视图：

static void address_space_update_topology(AddressSpace *as)
{
    MemoryRegion *physmr = memory_region_get_flatview_root(as->root);

    flatviews_init();
    if (!g_hash_table_lookup(flat_views, physmr)) {
        generate_memory_topology(physmr);
    }
    address_space_set_flatview(as);
}

address_space_update_topology()会先调用generate_memory_topology()生成system_memory更新后的视图new_view，再将address_space_memory的current_map指向这个new_view，最后销毁old_view：

static void address_space_set_flatview(AddressSpace *as)
{
    FlatView *old_view = address_space_to_flatview(as);
    MemoryRegion *physmr = memory_region_get_flatview_root(as->root);
    FlatView *new_view = g_hash_table_lookup(flat_views, physmr);

    assert(new_view);

    if (old_view == new_view) {
        return;
    }

    if (old_view) {
        flatview_ref(old_view);
    }

    flatview_ref(new_view);

    if (!QTAILQ_EMPTY(&as->listeners)) {
        FlatView tmpview = { .nr = 0 }, *old_view2 = old_view;

        if (!old_view2) {
            old_view2 = &tmpview;
        }
        address_space_update_topology_pass(as, old_view2, new_view, false);
        address_space_update_topology_pass(as, old_view2, new_view, true);
    }

    /* Writes are protected by the BQL.  */
    qatomic_rcu_set(&as->current_map, new_view);
    if (old_view) {
        flatview_unref(old_view);
    }

    /* Note that all the old MemoryRegions are still alive up to this
     * point.  This relieves most MemoryListeners from the need to
     * ref/unref the MemoryRegions they get---unless they use them
     * outside the iothread mutex, in which case precise reference
     * counting is necessary.
     */
    if (old_view) {
        flatview_unref(old_view);
    }
}

在address_space_update_topology_pass()的最后，会调用MEMORY_LISTENER_UPDATE_REGION这个宏，触发region_add对应的回调函数kvm_region_add()。

这个宏在memory.c中定义，会将 FlatView 中的 FlatRange 转换为 MemoryRegionSection，作为入参传递给kvm_region_add()：

/* No need to ref/unref .mr, the FlatRange keeps it alive.  */
#define MEMORY_LISTENER_UPDATE_REGION(fr, as, dir, callback, _args...)  \
    do {                                                                \
        MemoryRegionSection mrs = section_from_flat_range(fr,           \
                address_space_to_flatview(as));                         \
        MEMORY_LISTENER_CALL(as, callback, dir, &mrs, ##_args);         \
    } while(0)

而kvm_region_add()实际上是对kvm_set_phys_mem()的封装调用。该函数比较复杂，会根据传入的section填充 KVMSlot，再传递给kvm_set_user_memory_region()：


static int kvm_set_user_memory_region(KVMMemoryListener *kml, KVMSlot *slot, bool new)
{
    KVMState *s = kvm_state;
    struct kvm_userspace_memory_region mem;
    int ret;

    // 根据 KVMSlot 填充 kvm_userspace_memory_region
    mem.slot = slot->slot | (kml->as_id << 16);
    mem.guest_phys_addr = slot->start_addr;
    mem.userspace_addr = (unsigned long)slot->ram;
    mem.flags = slot->flags;

    if (slot->memory_size && !new && (mem.flags ^ slot->old_flags) & KVM_MEM_READONLY) {
        /* Set the slot size to 0 before setting the slot to the desired
         * value. This is needed based on KVM commit 75d61fbc. */
        mem.memory_size = 0;
        ret = kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem);
        if (ret < 0) {
            goto err;
        }
    }
    mem.memory_size = slot->memory_size;
    ret = kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem);
    slot->old_flags = mem.flags;
    return ret;
}

可以看到这里又将 KVMSlot 转换为 kvm_userspace_memory_region，作为ioctl()的参数，交给内核中的 KVM 进行内存的注册【设置GPA->HVA的映射关系，在内核空间维护并管理 Guest 的内存】。

至此 QEMU 侧负责管理内存的数据结构均已完成初始化，可以参考下面的图片了解各数据结构之间的对应关系

Responsive Image

实际内存的分配

Responsive Image

int main()
  └─ void machine->init(ram_size, ...)
       └─ static void pc_init_pci(ram_size, ...) // 初始化虚拟机
            └─ static void pc_init1(system_memory, system_io, ram_size, ...)
                 ├─ void memory_region_init(pci_memory, "pci", ...) // pci_memory, rom_memory
                 └─ void pc_memory_init() // 初始化内存，分配实际的物理内存地址
                      ├─ void memory_region_init_ram() // 创建 pc.ram, pc.rom 并分配内存
                      |    ├─ void memory_region_init()
                      |    └─ ram_addr_t qemu_ram_alloc()
                      |         └─ ram_addr_t qemu_ram_alloc_from_ptr()
                      |
                      ├─ void vmstate_register_ram_global() // 将 MR 的 name 写入 RAMBlock 的 idstr
                      |    └─ void vmstate_register_ram()
                      |         └─ void qemu_ram_set_idstr()
                      |
                      ├─ void memory_region_init_alias()    // 初始化 ram_below_4g, ram_above_4g
                      └─ void memory_region_add_subregion() // 在 system_memory 中添加 subregions
                           └─ static void memory_region_add_subregion_common()
                                └─ static void memory_region_update_topology() // 为 MemoryRegion 生成 FlatView
                                     └─ static void address_space_update_topology() // as->current_map = new_view
                                          └─ static void address_space_update_topology_pass()
                                               └─ static void kvm_region_add() // region_add 对应的回调实现
                                                    └─ static void kvm_set_phys_mem() // 根据传入的 section 填充 KVMSlot
                                                         └─ static int kvm_set_user_memory_region()
                                                              └─ int ioctl(KVM_SET_USER_MEMORY_REGION)

之前的回调函数注册、AddressSpace 的初始化，实际上均没有对应的物理内存。【实际的内存是在 RAMBlock 中】

我们再回到 qemu 启动的 main 函数中。接下来的初始化过程会调用 pc_init1。在这里面，对于 CPU 虚拟化，我们会调用 pc_cpus_init。另外，pc_init1 还会调用pc_memory_init，进行内存的虚拟化。

void *pc_memory_init(MemoryRegion *system_memory,
                    const char *kernel_filename,
                    const char *kernel_cmdline,
                    const char *initrd_filename,
                    ram_addr_t below_4g_mem_size,
                    ram_addr_t above_4g_mem_size,
                    MemoryRegion *rom_memory,
                    MemoryRegion **ram_memory)
{
    MemoryRegion *ram, *option_rom_mr;         // 两个实体 MR: pc.ram, pc.rom
    MemoryRegion *ram_below_4g, *ram_above_4g; // 两个别名 MR: ram_below_4g, ram_above_4g

    /* Allocate RAM.  We allocate it as a single memory region and use
     * aliases to address portions of it, mostly for backwards compatibility
     * with older qemus that used qemu_ram_alloc().
     */
    ram = g_malloc(sizeof(*ram)); // 创建 ram
    // 分配具体的内存（实际上会创建一个 RAMBlock 并将其 offset 值写入 ram.ram_addr，对应 GPA）
    memory_region_init_ram(ram, "pc.ram", below_4g_mem_size + above_4g_mem_size);
    // 将 MR 的 name 写入 RAMBlock 的 idstr
    vmstate_register_ram_global(ram);
    *ram_memory = ram;

    // 创建 ram_below_4g 表示 4G 以下的内存
    ram_below_4g = g_malloc(sizeof(*ram_below_4g));
    memory_region_init_alias(ram_below_4g, "ram-below-4g", ram, 0, below_4g_mem_size);
    // 将 ram_below_4g 挂在 system_memory 下
    memory_region_add_subregion(system_memory, 0, ram_below_4g);

    if (above_4g_mem_size > 0) {
        ram_above_4g = g_malloc(sizeof(*ram_above_4g));
        memory_region_init_alias(ram_above_4g, "ram-above-4g", ram, below_4g_mem_size, above_4g_mem_size);
        memory_region_add_subregion(system_memory, 0x100000000ULL, ram_above_4g);
    }
    /* ... */
}

这里的重点在于memory_region_init_ram()，它通过qemu_ram_alloc()获取 ram 这个 MemoryRegion 对应的 RAMBlock 的offset，并存入ram.ram_addr，这样就可以在ram_list中根据该字段查找 MR 对应的 RAMBlock：

void memory_region_init_ram(MemoryRegion *mr, const char *name, uint64_t size)
{
    memory_region_init(mr, name, size); // 填充字段，初始化默认值
    mr->ram = true; // 表示为 RAM
    mr->terminates = true; // 表示为实体 MemoryRegion
    mr->destructor = memory_region_destructor_ram;
    mr->ram_addr = qemu_ram_alloc(size, mr); // 这里保存 RAMBlock 的 offset，即 GPA
}

而 qemu_ram_alloc() 最终会调用 qemu_ram_alloc_from_ptr()，创建一个对应大小 RAMBlock 并分配内存，返回对应的 GPA 地址存入 mr->ram_addr 中：

ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
                                   MemoryRegion *mr)
{
    RAMBlock *new_block; // 创建一个 RAMBlock

    size = TARGET_PAGE_ALIGN(size); // 页对齐
    new_block = g_malloc0(sizeof(*new_block)); // 初始化 new_block

    new_block->mr = mr; // 将 new_block-> 指向入参的 MemoryRegion
    new_block->offset = find_ram_offset(size); // 从 ram_list 中的 RAMBlock 之间找到一段可以满足 size 需求的 gap，并返回起始地址的 offset，对应 GPA
    if (host) { // 新建的 RAMBlock host 字段为空，跳过
        new_block->host = host;
        new_block->flags |= RAM_PREALLOC_MASK;
    } else {
        if (mem_path) { // 未指定 mem_path
#if defined (__linux__) && !defined(TARGET_S390X)
            new_block->host = file_ram_alloc(new_block, size, mem_path);
            if (!new_block->host) {
                new_block->host = qemu_vmalloc(size);
                qemu_madvise(new_block->host, size, QEMU_MADV_MERGEABLE);
            }
#else
            fprintf(stderr, "-mem-path option unsupported\n");
            exit(1);
#endif
        } else {
            if (xen_enabled()) {
                xen_ram_alloc(new_block->offset, size, mr);
            } else if (kvm_enabled()) { // 从这里继续
                /* some s390/kvm configurations have special constraints */
                new_block->host = kvm_vmalloc(size); // 实际上还是调用 qemu_vmalloc(size)
            } else {
                new_block->host = qemu_vmalloc(size); // 从 QEMU 的线性空间中分配 size 大小的内存，返回 HVA
            }
            qemu_madvise(new_block->host, size, QEMU_MADV_MERGEABLE);
        }
    }
    new_block->length = size; // 将 length 设置为 size

    QLIST_INSERT_HEAD(&ram_list.blocks, new_block, next); // 将该 RAMBlock 插入 ram_list 头部

    ram_list.phys_dirty = g_realloc(ram_list.phys_dirty, // 重新分配 ram_list.phys_dirty 的内存空间
                                       last_ram_offset() >> TARGET_PAGE_BITS);
    memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
           0, size >> TARGET_PAGE_BITS);
    cpu_physical_memory_set_dirty_range(new_block->offset, size, 0xff); // 对该 RAMBlock 对应的内存标记为 dirty

    qemu_ram_setup_dump(new_block->host, size);

    if (kvm_enabled())
        kvm_setup_guest_memory(new_block->host, size);

    return new_block->offset;
}

这样一来ram【其实就是system memory，整个Guest物理空间的大小】对应的 RAMBlock 中就分配好了 GPA 和 HVA，就可以将内存信息同步至 KVM 侧了。

最后回到pc_memory_init()中，在分配完实际内存后，会先调用memory_region_init_alias()初始化ram_below_4g、ram_above_4g这两个alias，之后调用memory_region_add_subregion()将这两个 alias 指向ram这个实体 MemoryRegion。如下图，该函数最终会触发kvm_region_add()回调，将实际的内存信息传入 KVM 注册。该过程如下图所示，与之前分析的流程相同，此处不再赘述。

Responsive Image

总结

虚拟机的内存管理也是需要用户态的 qemu 和内核态的 KVM 共同完成。为了加速内存映射，需要借助硬件的 EPT 技术。

QEMU 侧

创建一系列 MemoryRegion，分别表示 Guest 中的 RAM、ROM 等区域。MemoryRegion之间通过 alias 或 subregions 的方式维护相互之间的关系，从而进一步细化区域的定义
对于一个实体 MemoryRegion（非 alias），在初始化内存的过程中 QEMU 会创建它所对应的 RAMBlock。该 RAMBlock 通过调用qemu_ram_alloc_from_ptr()从 QEMU 的进程地址空间中以 mmap 的方式分配内存，并负责维护该 MemoryRegion 对应内存的起始 GPA/HVA/size 等相关信息【在qemu_ram_alloc_from_ptr中创建的新RAMBlock有offset、host的赋值，即GPA->HVA的对应关系】
AddressSpace 表示 Guest 的物理地址空间。如果 AddressSpace 中的 MemoryRegion 发生变化，则注册的 listener 会被触发，将所属的 MemoryRegion 树展开生成一维的 FlatView，比较 FlatRange 是否发生了变化。如果是，则调用相应的方法对 MemoryRegionSection 进行检查，更新 QEMU 中的 KVMSlot，同时填充kvm_userspace_memory_region结构体，作为ioctl()的参数更新 KVM 中的kvm_memory_slot

KVM 侧

当 QEMU 通过ioctl()创建 vcpu 时，调用kvm_mmu_create()初始化 MMU 相关信息。当 KVM 要进入 Guest 前，vcpu_enter_guest()=>kvm_mmu_reload()会将根级页表地址加载到 VMCS，让 Guest 使用该页表
当发生EPT Violation 时，VM-EXIT到 KVM 中。如果是缺页，则根据 GPA 算出 gfn，再根据 gfn 找到对应的 KVMSlot，从中得到对应的 HVA。然后根据 HVA 算出对应的 pfn，确保该 Page 位于内存中。填好缺失的页之后，需要更新 EPT，完善其中缺少的页表项，逐层补全页表

Responsive Image

虚拟机的物理内存空间里面的页面当然不是一开始就映射到物理页面的，只有当虚拟机的内存被访问的时候，也即 mmap 分配的虚拟内存空间被访问的时候，先查看 EPT 页表，是否已经映射过，如果已经映射过，则经过四级页表映射，就能访问到物理页面。如果没有映射过，则虚拟机会通过VM-Exit指令回到宿主机模式，通过 handle_ept_violation 补充页表映射。先是通过 handle_mm_fault为虚拟机的物理内存空间分配真正的物理页面，然后通过 __direct_map 添加 EPT 页表映射。 Responsive Image

Reference

“QEMU 内存空间虚拟化及内存管理” - B10g | FΓom 许大仙【原创】Linux 虚拟化 KVM-Qemu 分析（五）之内存虚拟化 - LoyenWang - 博客园 KVM/Qemu 工作原理系列目录_xiongwenwu 的专栏-CSDN 博客_qemu 目录结构 QEMU 内存虚拟化源码分析 | Keep Coding | 苏易北

QEMU 源码分析-外设模拟（以 GPIO 为例）

Thu, 11 Nov 2021 10:11:32 +0000

QEMU 模拟外设的原理

QEMU 主要是实现了 CPU 核的模拟，可以读写某个地址。 QEMU 的模拟外设的原理很简单：硬件即内存。要在 QEMU 上模拟某个外设，思路就是：

CPU 读某个地址时，QEMU 模拟外设的行为，把数据返回给 CPU
CPU 写某个地址时，QEMU 获得数据，用来模拟外设的行为。即：要模拟外设备，我们只需要针对外设的地址提供对应的读写函数即可。

以 GPIO 为例：

Responsive Image

QEMU 为GPIO内存地址提供读写回调函数，

static void sifive_gpio_write(void *opaque, hwaddr offset, uint64_t value, unsigned int size)

static uint64_t sifive_gpio_read(void *opaque, hwaddr offset, unsigned int size)

给外设地址提供读写函数

怎么描述某段地址：基地址、大小？如何给这段地址提供读写函数呢？这段地址设置好后，如何添加进system_memory去？有 2 种方法。

法 1：memory_region_init_io/memory_region_add_subregion 以SIFIVE_UART为例，

memory_region_init_io(&s->mmio, NULL, &uart_ops, s,
                        TYPE_SIFIVE_UART, 0x2000);
memory_region_add_subregion(address_space, base, &s->mmio);

memory_region_init_io函数初始化iomem，读写函数，大小。 memory_region_add_subregion函数s->iomem指定了基地址，并添加进system_memory中。以后，客户机上的程序读写这块地址时，就会导致对应的读写函数被调用。

法 2：memory_region_init_io/sysbus_init_mmio/sysbus_mmio_map 以SIFIVE_GPIO为例，

memory_region_init_io(&s->mmio, OBJECT(dev), &gpio_ops, s, TYPE_SIFIVE_GPIO, SIFIVE_GPIO_SIZE);

sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->mmio);

memory_region_init_io函数初始化iomem，读写函数，大小。 sysbus_init_mmio将mmin传给设备；

sysbus_mmio_map(SYS_BUS_DEVICE(&s->gpio), 0, memmap[SIFIVE_E_DEV_GPIO0].base);

sysbus_mmio_map从设备中吧mmio添加进system_memory并指定基地址。

QEMU 源码分析 - 虚拟外设创建

Tue, 09 Nov 2021 17:39:38 +0000

QOM 简介

这个模型主要包含四个结构体：

Object: 是所有对象的基类 Base Object
ObjectClass: 是所有类对象的基类
TypeInfo：是用户用来定义一个 Type 的工具型的数据结构
TypeImpl：TypeInfo 抽象数据结构，TypeInfo 的属性与 TypeImpl 的属性对应

在 QEMU 里要初始化一个对象需要完成四步：

将 TypeInfo 注册 TypeImpl
实例化 Class（ObjectClass）
实例化 Object
添加 Property

Responsive Image

如何描述硬件

一个板子上有很多硬件：芯片，LED、按键、LCD、触摸屏、网卡等等。芯片里面也有很多部件，比如 CPU、GPIO、SD 控制器、中断控制器等等。

这些硬件，或是部件，各有不同。怎么描述它们？

每一个都使用一个 TypeInfo 结构体来描述，TypeInfo 是用户用来定义一个 Type 的工具型的数据结构。它包含了很多成员变量，这些成员合在一起描述了一个设备类型。

// include/qom/object.h
struct TypeInfo
{
    const char *name;
    const char *parent;
    size_t instance_size;
    size_t instance_align;
    void (*instance_init)(Object *obj);
    void (*instance_post_init)(Object *obj);
    void (*instance_finalize)(Object *obj);
    bool abstract;
    size_t class_size;    void (*class_init)(ObjectClass *klass, void *data);
    void (*class_base_init)(ObjectClass *klass, void *data);
    void *class_data;    InterfaceInfo *interfaces;
};

这个结构体我们在刚刚也提到，他在图里是独立的，在注册的时候会将它的信息都传给 Typeimpl 结构体。

我们以 Timer 为例，我们要添加一个 Timer 外设，首先就要定义一个 Typeinfo 结构体。他在代码中像这样。我们只看 name，这里用一个宏赋值，这个宏是个我们定义的字符串，它唯一标识了这个硬件。这些结构体在运行时会被注册进程序里，保存在一个链表中备用，为什么是备用，因为不是每一个硬件都会被用到。

// hw/timer/dw_timer.c
static const TypeInfo dw_timer_info = {
    .name          = TYPE_DW_TIMER,
    .parent        = TYPE_SYS_BUS_DEVICE,
    .instance_size = sizeof(DWTimerState),
    .instance_init = dw_timer_init,
    .class_init    = dw_timer_class_init,
};

这些结构体在运行时会被注册进程序里，保存在一个链表中备用，为什么是备用，因为不是每一个硬件都会被用到。

如何注册硬件

什么是注册，说白了就是将一些可能需要的信息添加到系统中，在系统运行时能够随时调用到。就拿 Timer 来说，现在将一些信息添加到了列表，系统运行起来时我可以随时从链表中取出 Timer 这个设备的信息，用来实例化一个 Timer，但是我没有注册 Timer，也就是没有将其加入到链表，那我后期就无法找到它。

怎么注册这些TypeInfo结构体呢？在实现的源码中有这个函数 dw_timer_register_types()，他是用来注册 Timer 这个设备的。

我们追根溯源，调用过程如下，

Responsive Image

分配一个 TypeImpl 结构体，使用 Typeinfo 来设置它
把 TypeImpl 加入链表：type_table

在 QEMU 里面，有一个全局的哈希表 type_table，用来存放所有定义的类。在 type_new 里面，我们先从全局表里面根据名字 type_table_lookup 查找找这个类。

如果找到，说明这个类曾经被注册过，就报错；
如果没有找到，说明这是一个新的类，则将 Typeinfo 里面信息填到 TypeImpl 里面。type_table_add 会将这个类注册到全局的表里面。

Responsive Image

以上的过程可以用上图来表示。Typeinfo 通过 type_new() 生成一个对应的 TypeImpl 类型，并以 name 为关键字添加到名为 type_table 的一个 hash table 中。

什么时候注册这些设备呢？不需要我们去调用注册函数，以 Timer 为例，在 hw/timer/dw_timer.c 中有如下代码，一般在最后一行：

type_init(dw_timer_register_types)

F12找到这个宏定义，我们追根溯源，调用过程如下

type_init()
    -> module_init()
        -> register_module_init()

type_init(dw_timer_register_types)

#define type_init(function) module_init(function, MODULE_INIT_QOM)

#define module_init(function, type)                                         \
static void __attribute__((constructor)) do_qemu_init_ ## function(void)    \
{                                                                           \
    register_module_init(function, type);                                   \
}

void register_module_init(void (*fn)(void), module_init_type type)
{
    ModuleEntry *e;     //构造 ModuleEntry
    ModuleTypeList *l;  //构造链表

    e = g_malloc0(sizeof(*e));
    e->init = fn;       //设置初始化函数，fn 即 sifive_gpio_register_types
    e->type = type;

    l = find_type(type);

    QTAILQ_INSERT_TAIL(l, e, node);//将 ModuleEntry 插入链表尾
}

type_init是个宏定义，调用了__attribute__((constructor))函数，我们知道这个 C 语言中位数不多的在main函数执行前，执行的函数。函数中调用了register_module_init注册函数，说明在main函数执行前，已经注册好硬件了。该函数将一个新的ModuleEntry加到链表里。

注意，注册的只是个函数，并不是注册了设备。也就是已上过程，只是把一个 ModuleEntry 放到了一个链表里，这个 ModuleEntry 带了两个信息，一个是函数，一个是类型。这个函数就是我们真正的注册注册函数。

已上过程大概是如下所示：

Responsive Image

那什么时候还真正注册设备呢，我们就得回到主函数，它有以下调用流程，在 module_call_init 中，我们会找到 MODULE_INIT_QOM 这种类型对应的 ModuleTypeList 找出列表中所有的 ModuleEntry，然后调用每个 ModuleEntry 的 init 函数。

Responsive Image

// softmmu/runstate.c
module_call_init(MODULE_INIT_QOM);

// utils/module.csoftmmu/runstate.c
void module_call_init(module_init_type type)
{
    ModuleTypeList *l;
    ModuleEntry *e;
    // 找到 MODULE_INIT_QOM 这种类型对应的 ModuleTypeList
    l = find_type(type);
    QTAILQ_FOREACH(e, l, node) {
        e->init();
    }
}

初始化设备

到这里我们需要注意，我们在注册设备的时候虽然将设备从 Typeinfo 变成了 TypeImpl，把 Typeinfo 里的信息都复制到了 TypeImpl，但是 class_init 还没有被调用，也即这个类现在还处于纸面的状态。

什么时候才真正初始化这个类呢，这得等在用到它的时候。我们在一块板子上才会用到一个设备。我们使用的是 Sifive-e 这个板子，准确来说我们用的不是这个板子，我们只是在原先的代码上做了修改。

为了方便描述，就当是用的 sifive-e 这个板子。在实现的源码里，有 object_initialize_child函数，跟踪一下调用流程可以看到最后在 type_initialize 函数中初始化了类。同时我们也看到在 object_init_with_type 函数中实例化了类。这个稍后再讲。

// hw/riscv/sifive_e.cstatic void sifive_e_soc_init(Object *obj)
{
    MachineState *ms = MACHINE(qdev_get_machine());
    SiFiveESoCState *s = RISCV_E_SOC(obj);
	.
	.
	.    object_initialize_child(obj, "timer", &s->timer,
                            TYPE_DW_TIMER);
}

object_initialize_child(obj, name, &s->timer, TYPE_DW_TIMER);
    object_initialize_child_internal()
        object_initialize_child_with_props()
            object_initialize_child_with_propsv()
                object_initialize()
                    object_initialize_with_type()
                        type_initialize()
                        {
                            if (ti->class_init) {
                                ti->class_init(ti->class, ti->class_data);
                            }
                        }
                        object_init_with_type()
                        {       
                            if (ti->instance_init) {
                                ti->instance_init(obj);
                            }
                        }

在调用 class_init 函数时，其实就是调用的设备模块下的 dw_timer_class_init，这个函数中又是一些配置，尤其是 realize 函数的配置。还有一些属性的配置，如 Timer 的频率。

到这里，我们才有有了一个真正意义上的设备类。

hw/timer/dw_timer.c 
static void dw_timer_class_init(ObjectClass *klass, void *data)
{
    // 这里又是一些配置，尤其是回调函数的配置
    DeviceClass *dc = DEVICE_CLASS(klass);
    dc->reset = dw_timer_reset;
    // 设置 Timer 基本属性如频率等
    device_class_set_props(dc, dw_timer_properties);
    dc->vmsd = &vmstate_dw_timer;
    dc->realize = dw_timer_realize;
}

实例化设备

说白了初始化过程就是在配置各种结构体成员的过程，比如刚刚的初始化过程就是在配置 DeviceClass 这个类的各个成员。实际上我们还没有真正实例化 Timer，我们还不能使用它。

我们只有在实例化后才能使用它，也就是之前提到的 instance_init()。但是在 QEMU 中要实例化一个设备，不仅仅需要调用 instance_init，还需要调用刚刚初始化时设置的 realize 函数。

static const TypeInfo dw_timer_info = {
    .name          = TYPE_DW_TIMER,
    .parent        = TYPE_SYS_BUS_DEVICE,
    .instance_size = sizeof(DWTimerState),
    .instance_init = dw_timer_init,
    .class_init    = dw_timer_class_init,
};
// hw/timer/dw_timer.c
static void dw_timer_init(Object *obj)
{
    DWTimerState *s = DWTIMER(obj);
    // 为这段内存注册回调函数
    memory_region_init_io(&s->iomem, obj, &dw_timer_ops, s,
                          "dw_timer", 0x2000);
    sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->iomem);
}

这两个函数的功能很像，具体细节差异我也还没弄明白，但是需要注意的是 instance_init 一定要在 realize 之前完成，并且没有错误。否则将无法完成实例化。

// hw/timer/dw_timer.c
static void dw_timer_realize(DeviceState *dev, Error **errp)
{
    DWTimerState *s = DWTIMER(dev);
    sysbus_init_irq(SYS_BUS_DEVICE(dev), &s->irq);
    for (int i = 0; i < n; i++) {
        s->timer[i] = timer_new_ns(QEMU_CLOCK_VIRTUAL, dw_timer_interrupt, s);
    }
}

instance_init 这个函数主要完成的工作就是为一段内存绑定了读写函数，为什么要这么做，我们再往下看。

如何操作设备

设备创建完成了，那 QEMU 是如何模拟设备的行为的？这也是 QEMU 驱动开发最重要的一步，因为以上的部分是实现设备所必须的，我们只需要参考其他已经实现的模块，修改成我们的信息即可。

但是每个 IP 的寄存器不同，他们的功能也就不同，这是我们真正需要实现的内容。我们知道写驱动其实就是操作各个 IP 的寄存器，以实现想要的功能。对应到 QEMU 中，就成了在操作各个寄存器时，我们要在 QEMU 中将驱动寄存器的功能先模拟出来，再返回给驱动程序。

以 Timer 为例我想要获取 TimerNLoadCount 的值，真实硬件有这个寄存器保存了值，但是 QEMU 上我们就得维护一个变量去保存这个值。在需要的时候能读取到。比如代码里比较重要的参数是 offset，这个参数是基于外设基地址的偏移，其实就是寄存器的偏移量。比如我们查看 Timer 的手册，TimerNLoadCount 偏移量为 0，所以当我们在驱动中读取地址为 0x2000000 时，代码就会走到这里，因为我们维护了一个 timer_n_load_count 变量，所以我直接将这个变量当前值返回即可，这就是这个寄存器的值。我们要写这个寄存器也同理，我们需要更新 timer_n_load_count 这个变量。

// hw/timer/dw_timer.c
static uint64_t dw_timer_read(void *opaque, hwaddr offset,
                           unsigned size)
{
    DWTimerState *s = opaque;
    int index = 0;
    switch (offset) {
    case TimerNLoadCount:
    case 1*0x14:
    case 2*0x14:
        index = offset / 0x14;
        return s->timer_n_load_count[index];
.
.
.
}

static void dw_timer_write(void *opaque, hwaddr offset,
                        uint64_t val64, unsigned size)
{
    DWTimerState *s = opaque;
    uint32_t value = val64;
    int index = 0;
    int change = 0;    switch (offset) {
    case TimerNLoadCount:
    case 1*0x14:
    case 2*0x14:
        index = (offset) / 0x14;
        s->timer_n_load_count[index] = value;
        set_alarm_time(s,index);
        return;
.
.
.
}

读写函数写好了，需要给谁调用呢。我们刚刚提到了，这是个回调函数，我们需要给一段内存注册这个回调函数。如代码所示。我们给 Timer iomem 绑定了读写函数。具体哪一段地址还没定，但是我们定了 0x2000 这么长一段。我觉得这里应该是最高位的一个寄存器偏移量。因为再高就没啥用了，或者就是 SoC 里定的寄存器空间大小 0x1000。这里应该是为了图省事写的一个值。

// hw/timer/dw_timer.c
static const MemoryRegionOps dw_timer_ops = {
    .read = dw_timer_read,
    .write = dw_timer_write,
    .endianness = DEVICE_NATIVE_ENDIAN,
};


static void dw_timer_init(Object *obj)
{
    DWTimerState *s = DWTIMER(obj);
    // 为这段内存注册回调函数
    memory_region_init_io(&s->iomem, obj, &dw_timer_ops, s,
                          "dw_timer", 0x2000);
    sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->iomem);
}

下面在hw/riscv/sifive_e.c里会映射寄存器空间到 QEMU 的内存空间。

// hw/riscv/sifive_e.c
sysbus_mmio_map(SYS_BUS_DEVICE(&s->timer), 0, memmap[SIFIVE_E_DEV_TIMER].base);

参考

QEMU 中基于 QOM 的 VFIO 类的定义 - EwanHai - 博客园

QEMU 源码分析-虚拟 CPU 创建

Wed, 01 Sep 2021 18:22:14 +0000

流程图

先开个头吧，把创建流程稍微捋一下，找到创建虚拟 CPU 的模块。至于中间的流程还没有详细分析，万事开头难，先上手再说吧。

Responsive Image

`qemu_add_opts`解析 qemu 的命令行

qemu_init函数中下面这一长串内容，就是在解析命令行的参数。

qemu add opts (&qemu drive opts);
qemu add drive opts(&qemu Legacy drive opts);
qemu add drive opts (&qemu common drive opts);
qemu add drive opts (&qemu drive opts);
qemu add drive opts (sbdry runtime opts);
qemu add opts (qemu chardev opts);
qemu add opts (&qemu device opts);
qemu add opts (&qemu netdev opts);
qemu add opts (&qemu nic opts);
qemu add opts (sqemu net opts
qemu add opts (&qemu rtc opts)
qemu add opts (&qemu global_opts);
qemu add opts (&qemu mon opts);
qemu add opts (sqemu trace opts);
.
.
.

为什么有这么多的 opts呢？这是因为，实际运行中创建的kvm参数会复杂N倍。这里我们贴一个开源云平台软件 OpenStack 创建出来的KVM的参数，如下所示。

qemu-system-x86_64
-enable-kvm
-name instance-00000024
-machine pc-i440fx-trusty,accel=kvm,usb=off
-cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
-m 2048
-smp 1,sockets=1,cores=1,threads=1
......
-rtc base=utc,driftfix=slew
-drive file=/var/lib/nova/instances/1f8e6f7e-5a70-4780-89c1-464dc0e7f308/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-netdev tap,fd=32,id=hostnet0,vhost=on,vhostfd=37
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:d1:2d:99,bus=pci.0,addr=0x3
-chardev file,id=charserial0,path=/var/lib/nova/instances/1f8e6f7e-5a70-4780-89c1-464dc0e7f308/console.log
-vnc 0.0.0.0:12
-device cirrus-vga,id=video0,bus=pci.0,addr=0x2

-enable-kvm：表示启用硬件辅助虚拟化。
-name instance-00000024：表示虚拟机的名称。
-machine pc-i440fx-trusty,accel=kvm,usb=off：machine 是什么呢？其实就是计算机体系结构。不知道什么是体系结构的话，可以订阅极客时间的另一个专栏《深入浅出计算机组成原理》。 qemu 会模拟多种体系结构，常用的有普通 PC 机，也即 x86 的 32 位或者 64 位的体系结构、Mac 电脑 PowerPC 的体系结构、Sun 的体系结构、MIPS 的体系结构，精简指令集。如果使用 KVM hardware-assisted virtualization，也即 BIOS 中 VD-T 是打开的，则参数中 accel=kvm。如果不使用 hardware-assisted virtualization，用的是纯模拟，则有参数 accel = tcg，-no-kvm。
-cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme：表示设置 CPU，SandyBridge 是 Intel 处理器，后面的加号都是添加的 CPU 的参数，这些参数会显示在 /proc/cpuinfo 里面。
-m 2048：表示内存。
-smp 1,sockets=1,cores=1,threads=1：SMP 我们解析过，叫对称多处理器，和NUMA 对应。qemu 仿真了一个具有 1 个 vcpu，一个 socket，一个 core，一个 threads 的处理器。 socket、core、threads 是什么概念呢？socket 就是主板上插 CPU 的槽的数目，也即常说的“路”，core 就是我们平时说的“核”，即双核、4 核等。thread 就是每个 core 的硬件线程数，即超线程。举个具体的例子，某个服务器是：2 路 4 核超线程（一般默认为 2 个线程），通过 cat /proc/cpuinfo，我们看到的是 242=16 个processor，很多人也习惯成为 16 核了。
-rtc base=utc,driftfix=slew：表示系统时间由参数 -rtc 指定。
-device cirrus-vga,id=video0,bus=pci.0,addr=0x2：表示显示器用参数 -vga 设置，默认为 cirrus，它模拟了 CL-GD5446PCI VGA card。
有关网卡，使用 -net 参数和 -device。
从 HOST 角度：-netdev tap,fd=32,id=hostnet0,vhost=on,vhostfd=37。
从 GUEST 角度：-device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:d1:2d:99,bus=pci.0,addr=0x3。
有关硬盘，使用 -hda -hdb，或者使用 -drive 和 -device。
从 HOST 角度：-drive file=/var/lib/nova/instances/1f8e6f7e-5a70-4780-89c1-464dc0e7f308/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none
从 GUEST 角度：-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-vnc 0.0.0.0:12：设置 VNC。

`module_call_init`初始化所有模块

int main()
--> qemu_init()
--> qemu_init_subsystems()
--> module_call_init()

当虚拟机真的要使用物理资源的时候，对下面的物理机上的资源要进行请求，所以它的工作模式有点儿类似操作系统对接驱动。驱动要符合一定的格式，才能算操作系统的一个模块。同理，qemu 为了模拟各种各样的设备，也需要管理各种各样的模块，这些模块也需要符合一定的格式。

定义一个 qemu 模块会调用 type_init。例如，kvm 的模块要在 accel/kvm/kvm-all.c 文件里面实现。在这个文件里面，有一行下面的代码：

static const TypeInfo kvm_accel_type = {
    .name = TYPE_KVM_ACCEL,
    .parent = TYPE_ACCEL,
    .instance_init = kvm_accel_instance_init,
    .class_init = kvm_accel_class_init,
    .instance_size = sizeof(KVMState),
};

static void kvm_type_init(void)
{
    type_register_static(&kvm_accel_type);
}

type_init(kvm_type_init);

找到type_init的定义

#define type_init(function) module_init(function, MODULE_INIT_QOM)

从代码里面的定义我们可以看出来，type_init 后面的参数是一个函数，调用 type_init 就相当于调用 module_init，在这里函数就是 kvm_type_init，类型就是 MODULE_INIT_QOM。

再查看一下module_init的定义

//include/qemu/module.h
#define module_init(function, type)                                         \
static void __attribute__((constructor)) do_qemu_init_ ## function(void)    \
{                                                                           \
    register_module_init(function, type);                                   \
}

module_init 最终要调用 register_module_init。属于 MODULE_INIT_QOM 这种类型的，有一个 Module 列表 ModuleTypeList，列表里面是一项一项的 ModuleEntry。KVM 就是其中一项，并且会初始化每一项的 init 函数为参数表示的函数 fn，也即 KVM 这个 module 的 init 函数就是 kvm_type_init。

当然，MODULE_INIT_QOM 这种类型会有很多很多的 module，从后面的代码我们可以看到，所有调用 type_init 的地方都注册了一个 MODULE_INIT_QOM 类型的 Module。

了解了 Module 的注册机制，我们继续回到 qemu_init_subsystems 函数中 module_call_init 的调用。

void qemu_init_subsystems(void)
{
    Error *err;
    os_set_line_buffering();
    module_call_init(MODULE_INIT_TRACE);
    qemu_init_cpu_list();
    qemu_init_cpu_loop();
    qemu_mutex_lock_iothread();
    atexit(qemu_run_exit_notifiers);
    module_call_init(MODULE_INIT_QOM);
    module_call_init(MODULE_INIT_MIGRATION);
.
.
.
}

// utils/module.c
void module_call_init(module_init_type type)
{
    ModuleTypeList *l;
    ModuleEntry *e;
    l = find_type(type);
    QTAILQ_FOREACH(e, l, node) {
        e->init();
    }
}

在 module_call_init 中，我们会找到 MODULE_INIT_QOM 这种类型对应的 ModuleTypeList，找出列表中所有的 ModuleEntry，然后调用每个 ModuleEntry 的 init 函数。这里需要注意的是，在 module_call_init 调用的这一步，所有 Module 的 init 函数都已经被调用过了。

后面我们会看到很多的 Module，当我们后面再次遇到时，需要意识到，它的 init 函数在这里也被调用过了。这里我们还是以对于 kvm 这个 module 为例子，看看它的 init 函数都做了哪些事情。我们会发现，其实它调用的是 kvm_type_init。

static void kvm_type_init(void)
{
    type_register_static(&kvm_accel_type);
}
TypeImpl *type_register_static(const TypeInfo *info)
{
    return type_register(info);
}
TypeImpl *type_register(const TypeInfo *info)
{
    assert(info->parent);
    return type_register_internal(info);
}
static TypeImpl *type_register_internal(const TypeInfo *info)
{
    TypeImpl *ti;
    ti = type_new(info);
 
    type_table_add(ti);
    return ti;
}
static TypeImpl *type_new(const TypeInfo *info)
{
    TypeImpl *ti = g_malloc0(sizeof(*ti));
    int i;
 
    if (type_table_lookup(info->name) != NULL) {
    }
    ti->name = g_strdup(info->name);
    ti->parent = g_strdup(info->parent);
    ti->class_size = info->class_size;
    ti->instance_size = info->instance_size;
    ti->class_init = info->class_init;
    ti->class_base_init = info->class_base_init;
    ti->class_data = info->class_data;
    ti->instance_init = info->instance_init;
    ti->instance_post_init = info->instance_post_init;
    ti->instance_finalize = info->instance_finalize;
    ti->abstract = info->abstract;
    for (i = 0; info->interfaces && info->interfaces[i].type; i++) {
        ti->interfaces[i].typename = g_strdup(info->interfaces[i].type);
    }
    ti->num_interfaces = i;
    return ti;
}
static void type_table_add(TypeImpl *ti)
{
    assert(!enumerating_types);
    g_hash_table_insert(type_table_get(), (void *)ti->name, ti);
}
static GHashTable *type_table_get(void)
{
    static GHashTable *type_table;
 
    if (type_table == NULL) {
        type_table = g_hash_table_new(g_str_hash, g_str_equal);
    }
 
    return type_table;
}
static const TypeInfo kvm_accel_type = {
    .name = TYPE_KVM_ACCEL,
    .parent = TYPE_ACCEL,
    .class_init = kvm_accel_class_init,
    .instance_size = sizeof(KVMState),
};

调用流程如下：虚线表示返回

Responsive Image

每一个 Module 既然要模拟某种设备，那应该定义一种类型 TypeImpl 来表示这些设备，这其实是一种面向对象编程的思路，只不过这里用的是纯 C 语言的实现，所以需要变相实现一下类和对象。

kvm_type_init 会注册 kvm_accel_type，定义上面的代码，我们可以认为这样动态定义了一个类。这个类的名字是 TYPE_KVM_ACCEL，这个类有父类 TYPE_ACCEL，这个类的初始化应该调用函数 kvm_accel_class_init。如果用这个类声明一个对象，对象的大小应该是 instance_size。

在 type_register_internal 中，我们会根据 kvm_accel_type 这个 TypeInfo，创建一个TypeImpl 来表示这个新注册的类，也就是说，TypeImpl 才是我们想要声明的那个 class。在 qemu 里面，有一个全局的哈希表 type_table，用来存放所有定义的类。在 type_new 里面，我们先从全局表里面根据名字type_table_lookup查找找这个类。如果找到，说明这个类曾经被注册过，就报错；如果没有找到，说明这是一个新的类，则将 TypeInfo 里面信息填到 TypeImpl 里面。type_table_add 会将这个类注册到全局的表里面。到这里，我们注意，class_init 还没有被调用，也即这个类现在还处于纸面的状态。

这点更加像 Java 的反射机制了。在 Java 里面，对于一个类，首先我们写代码的时候要写一个 class xxx 的定义，编译好就放在.class 文件中，这也是出于纸面的状态。然后，Java 会有一个 Class 对象，用于读取和表示这个纸面上的 class xxx，可以生成真正的对象。

相同的过程在后面的代码中我们也可以看到，class_init 会生成XXXClass，就相当于 Java 里面的 Class对象，TypeImpl 还会有一个 instance_init 函数，相当于构造函数，用于根据 XXXClass 生成 Object，这就相当于 Java 反射里面最终创建的对象。和构造函数对应的还有 instance_finalize，相当于析构函数。

这一套反射机制放在 qom 文件夹下面，全称 QEMU Object Model，也即用 C 实现了一套面向对象的反射机制。

初始化 machine

Responsive Image

//vl.c
qemu_create_machine (select_machine());

在创建 machine 之前，先要通过select_machine确定一个machine。select_machine又是怎么确定的呢，这就和我们命令行的输入有关，比如我们-m spike，那么这里就会选择spike作为machine。它的定义在hw/riscv/spike.c中。

在源码最后有这么一句，会和我们上面解析的type_init 是一样的，在全局的表里面注册了一个全局的名字是spike的纸面上的 class，也即 TypeImpl。

type_init(spike_machine_init_reqister_types)

现在全局表中有这个纸面上的 class 了。我们回到 select_machine。

在 select_machine 中，有两种方式可以生成 MachineClass。一种方式是 find_default_machine，找一个默认的；另一种方式是 machine_parse，通过解析参数生成 MachineClass。无论哪种方式，都会调用 object_class_get_list 获得一个 MachineClass 的列表，然后在里面找。

static MachineClass *select_machine(void)
{
    GSList *machines = object_class_get_list(TYPE_MACHINE, false);
    MachineClass *machine_class = find_default_machine(machines);
    const char *optarg;
    QemuOpts *opts;
    Location loc;
    loc_push_none(&loc);
    opts = qemu_get_machine_opts();
    qemu_opts_loc_restore(opts);
    optarg = qemu_opt_get(opts, "type");
    if (optarg) {
        machine_class = machine_parse(optarg, machines);
    }
    if (!machine_class) {
        error_report("No machine specified, and there is no default");
        error_printf("Use -machine help to list supported machines\n");
        exit(1);
    }
    loc_pop(&loc);
    g_slist_free(machines);
    return machine_class;
}

static MachineClass *find_default_machine(GSList *machines)
{
    GSList *el;
    MachineClass *default_machineclass = NULL;
    for (el = machines; el; el = el->next) {
        MachineClass *mc = el->data;

        if (mc->is_default) {
            assert(default_machineclass == NULL && "Multiple default machines");
            default_machineclass = mc;
        }
    }
    return default_machineclass;
}

static MachineClass *machine_parse(const char *name, GSList *machines)
{
    MachineClass *mc;
    GSList *el;
    if (is_help_option(name)) {
        printf("Supported machines are:\n");
        machines = g_slist_sort(machines, machine_class_cmp);
        for (el = machines; el; el = el->next) {
            MachineClass *mc = el->data;
            if (mc->alias) {
                printf("%-20s %s (alias of %s)\n", mc->alias, mc->desc, mc->name);
            }
            printf("%-20s %s%s%s\n", mc->name, mc->desc,
                   mc->is_default ? " (default)" : "",
                   mc->deprecation_reason ? " (deprecated)" : "");
        }
        exit(0);
    }
    mc = find_machine(name, machines);
    if (!mc) {
        error_report("unsupported machine type");
        error_printf("Use -machine help to list supported machines\n");
        exit(1);
    }
    return mc;
}

object_class_get_list 定义如下：

GSList *object_class_get_list(const char *implements_type,bool include_abstract)
{
    GSList *list = NULL;
    object_class_foreach(object_class_get_list_tramp,
                         implements_type, include_abstract, &list);
    return list;
}

void object_class_foreach(void (*fn)(ObjectClass *klass, void *opaque),
                          const char *implements_type, bool include_abstract,
                          void *opaque)
{
    OCFData data = { fn, implements_type, include_abstract, opaque };

    enumerating_types = true;
    g_hash_table_foreach(type_table_get(), object_class_foreach_tramp, &data);
    enumerating_types = false;
}

在全局表 type_table_get() 中，对于每一项 TypeImpl，我们都执行 object_class_foreach_tramp。

static void object_class_foreach_tramp(gpointer key, gpointer value,
                                       gpointer opaque)
{
    OCFData *data = opaque;
    TypeImpl *type = value;
    ObjectClass *k;
    type_initialize(type);
    k = type->class;
    if (!data->include_abstract && type->abstract) {
        return;
    }
    if (data->implements_type && 
        !object_class_dynamic_cast(k, data->implements_type)) {
        return;
    }
    data->fn(k, data->opaque);
}

在 object_class_foreach_tramp 中，会调用将 type_initialize，这里面会调用 class_init 将纸面上的 class 也即 TypeImpl 变为 ObjectClass，ObjectClass 是所有Class 类的祖先，MachineClass 是它的子类。

因为在 machine 的命令行里面，我们指定了名字为spike，就肯定能够找到我们注册过了的 TypeImpl，并调用它的 class_init 函数。

所以，当 select_machine 执行完毕后，就有一个 MachineClass 了。

接着，我们回到 qemu_create_machine 中的object_new_with_class。这就很好理解了，MachineClass 是一个 Class 类，接下来应该通过它生成一个 Instance，也即对象，这就是 object_new_with_class 的作用。

object_new_with_class 中，TypeImpl 的 instance_init 会被调用，创建一个对象。current_machine 就是这个对象，它的类型是MachineState。

Object *object_new_with_class(ObjectClass *klass)
{
    return object_new_with_type(klass->type);
}
static Object *object_new_with_type(Type type)
{
    Object *obj;
    type_initialize(type);
    obj = g_malloc(type->instance_size);
    object_initialize_with_type(obj, type->instance_size, type);
    obj->free = g_free;

    return obj;
}

至此，绕了这么大一圈，有关体系结构的对象才创建完毕，接下来很多的设备的初始化，包括 CPU 和内存的初始化，都是围绕着体系结构的对象来的，后面我们会常常看到current_machine。

Responsive Image

参考

Qemu CPU 虚拟化 - 人生一世，草木一秋。 - 博客园【原创】Linux 虚拟化 KVM-Qemu 分析（四）之 CPU 虚拟化（2） - LoyenWang - 博客园

VSCode 单步调试 QEMU

Tue, 24 Aug 2021 19:24:08 +0000

了解了如何在VSCode 中调试程序，接下来我们在 VSCode 中搭建调试 QEMU 的环境。

配置

首先我们需要下载和编译 QEMU 源码

./configure --enable-debug --target-list=riscv32-softmmu,riscv32-linux-user --enable-kvm

一定要加上--enable-debug，编译出的程序才带有调试信息，不用设置安装路径，编译时会自动在 qemu 文件夹下自动创建一个build文件夹，编译后的程序也在build文件夹下。

用 VSCode 打开qemu-6.X.X文件夹，Ctrl+Shift+D打开调试配置。如果参考过VSCode 中调试程序这篇文章，接下来就很容易。我们只需要将launch.jason文件中的program属性改为${workspaceFolder}/build/qemu-system-riscv32即可。

调试

打开qemu-6.X.X/softmmu/main.c文件，在main函数入口处打上断点，即可开始调试。

Responsive Image

现在只需要点击屏幕上的图标，就可以快速的进行单步调试。

如果需要进行命令行操作，在屏幕下方打开DEBUG CONSOLE，输入-exec+正常命令行下的命令即可在命令行中进行更多的调试。如查看断点信息-exec info breakpoints

Responsive Image

在 QEMU 上运行 64 位和 32 位 RISC-V-Linux

Wed, 28 Jul 2021 13:47:56 +0000

制作交叉工具链 riscv-gnu-toolchain

下载源码

这个仓库是我遇到的最难下载的一个仓库了，公司网慢和虚拟机性能差都脱不了干系。估计下载了五小时都不止，刚开始还指望一个命令所有子模块都下载完的，结果愣是等了半天中断了。试了两次后放弃了。如果各位看官能一次完成，那您是福大。

国内的码云平台有个Gitee 极速下载项目，上面有 GitHub 的一些常用开源项目的镜像，可供加速下载。


# riscv-gnu-toolchain
https://gitee.com/mirrors/riscv-gnu-toolchain.git

下载时问题出现了，如果下载子模块仍然会卡住，如果不加--recursive就只能下载主体内容，子模块都没有。（以下内容为第一安装时的方法，后续又找到了git clone 快速下载子模块的方法）

开始下载时不加--recursive参数，只下载riscv-gnu-toolchain的主体内容，然后进入到riscv-gnu-toolchain文件夹下，手动下载子模块的内容。

当下完riscv-binutils继续下载riscv-gdb时发现这两个项目是同一个项目，只是不同的分支。但是码云上并没有区分，但是我也没找到在码云上的对应分支。只能用油猴脚本了。

如果你有油猴插件可以去greasyfork搜索安装GitHub 镜像访问，加速下载这个脚本，刷新 GitHub 仓库界面就会多出几个镜像地址，一般下载都会快好几倍。如果不用油猴插件的可以用我复制好的链接。

Responsive Image

# riscv-binutils
git clone https://gitee.com/mirrors/riscv-binutils-gdb.git
# riscv-gcc
git clone https://gitee.com/mirrors/riscv-gcc.git
# riscv-dejagnu
git clone https://gitee.com/mirrors/riscv-dejagnu.git
# riscv-glibc
git clone https://gitee.com/mirrors/riscv-glibc.git
# riscv-newlib
git clone https://gitee.com/mirrors/riscv-newlib.git
# riscv-gdb
git clone --depth=1 https://hub.fastgit.org/riscv/riscv-binutils-gdb.git

编译 riscv-gnu-toolchain

提前安装如下软件：

sudo apt-get install autoconf automake autotools-dev curl python3 libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc zlib1g-dev libexpat-dev

不听老人言，吃亏在眼前呀，本以为这是可选项，很多库都安装了，就没有操作这一步，结果就是编译半天结果还错了。如果报make 错误 127，那就老老实实把前置的这些库都装上。

建立riscv-gnu-toolchain安装目录/opt/riscv64。

./configure --prefix=/opt/riscv64 
sudo make linux -j8

导出安装路径

export PATH="$PATH:/opt/riscv64/bin"

出现一下信息表示安装成功。

Using built-in specs.
COLLECT_GCC=riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/opt/riscv64/libexec/gcc/riscv64-unknown-linux-gnu/10.2.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /home/dominic/riscv64-linux/riscv-gnu-toolchain/riscv-gcc/configure --target=riscv64-unknown-linux-gnu --prefix=/opt/riscv64 --with-sysroot=/opt/riscv64/sysroot --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=.././riscv-gcc --disable-multilib --with-abi=lp64d --with-arch=rv64imafdc --with-tune=rocket 'CFLAGS_FOR_TARGET=-O2   -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2   -mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)

制作内核

下载 Linux 内核

makefile

QEMU 文档

Tue, 27 Jul 2021 11:12:01 +0000

调用文档

qemu-system-x86_64 [options] [disk_image] disk_image是 IDE 硬盘 0 的原始硬盘映像。某些目标不需要磁盘映像。

标准参数 Standard options

`-h`

功能显示帮助信息并退出
子参数
调用实例
```
qemu-system-riscv32 -h
```

`-version`

功能显示 qemu 版本信息并退出
子参数
调用实例
```
qemu-system-riscv32 -version
```

`-machine [type=]name[,prop=value[,...]]`

功能通过名称选择模拟器。使用 -machine help 可以查看可用的模拟器。对于支持跨版本实时迁移兼容性的架构，每个版本都会引入一个新的版本化模拟器类型。例如，2.8.0 版本为 x86_64/i686 架构引入了“pc-i440fx-2.8”和“pc-q35-2.8”。
子参数为了允许用户从 QEMU 2.8.0 版实时迁移到 QEMU 2.9.0 版，2.9.0 版也必须支持“pc-i440fx-2.8”和“pc-q35-2.8”机器。为了允许用户在升级时实时迁移 VMs 跳过多个中间版本，QEMU 的新版本将支持多个以前版本的机器类型。支持的机器属性有：
- accel=accels1[:accels2[:...]] This is used to enable an accelerator. Depending on the target architecture, kvm, xen, hax, hvf, nvmm, whpx or tcg can be available. By default, tcg is used. If there is more than one accelerator specified, the next one is used if the previous one fails to initialize.
- vmport=on|off|auto Enables emulation of VMWare IO port, for vmmouse etc. auto says to select the value based on accel. For accel=xen the default is off otherwise the default is on.
- dump-guest-core=on|off Include guest memory in a core dump. The default is on.
- mem-merge=on|off Enables or disables memory merge support. This feature, when supported by the host, de-duplicates identical memory pages among VMs instances (enabled by default).
- aes-key-wrap=on|off Enables or disables AES key wrapping support on s390-ccw hosts. This feature controls whether AES wrapping keys will be created to allow execution of AES cryptographic functions. The default is on.
- dea-key-wrap=on|off Enables or disables DEA key wrapping support on s390-ccw hosts. This feature controls whether DEA wrapping keys will be created to allow execution of DEA cryptographic functions. The default is on.
- nvdimm=on|off Enables or disables NVDIMM support. The default is off.
- memory-encryption= Memory encryption object to use. The default is none.
- hmat=on|off Enables or disables ACPI Heterogeneous Memory Attribute Table (HMAT) support. The default is off.
- memory-backend='id' An alternative to legacy -mem-path and mem-prealloc options. Allows to use a memory backend as main RAM. For example: :: -object memory-backend-file,id=pc.ram,size=512M,mem-path=/hugetlbfs,prealloc=on,share=on -machine memory-backend=pc.ram -m 512M Migration compatibility note: a) as backend id one shall use value of ‘default-ram-id’, advertised by machine type (available via query-machines QMP command), if migration to/from old QEMU (<5.0) is expected. b) for machine types 4.0 and older, user shall use x-use-canonical-path-for-ramblock-id=off backend option if migration to/from old QEMU (<5.0) is expected. For example: :: -object memory-backend-ram,id=pc.ram,size=512M,x-use-canonical-path-for-ramblock-id=off -machine memory-backend=pc.ram -m 512M

调用实例：

qemu-system-riscv32 -machine virt,mem-merge=on

`-cpu model`

功能选择 CPU 型号（-cpu help显示帮助列表和附加功能的选项）

默认情况会给客户机提供 qemu64 或 qemu32 的基本 CPU 模型。这样做可以对 CPU 特性提供一些高级的过滤功能，让客户机在同一组硬件平台上的动态迁移会更加平滑和安全。在客户机中查看 CPU 信息 (cat /proc/cpuinfo)，model name 就是当前 CPU 模型的名称。

调用实例
```
qemu-system-riscv32 -cpu rv32
```

`accel name[,prop=value[,...]]`

功能 This is used to enable an accelerator. Depending on the target architecture, kvm, xen, hax, hvf, nvmm, whpx or tcg can be available. By default, tcg is used. If there is more than one accelerator specified, the next one is used if the previous one fails to initialize.
子参数
- igd-passthru=on|off When Xen is in use, this option controls whether Intel integrated graphics devices can be passed through to the guest (default=off)
- kernel-irqchip=on|off|split Controls KVM in-kernel irqchip support. The default is full acceleration of the interrupt controllers. On x86, split irqchip reduces the kernel attack surface, at a performance cost for non-MSI interrupts. Disabling the in-kernel irqchip completely is not recommended except for debugging purposes.
- kvm-shadow-mem=size Defines the size of the KVM shadow MMU.
- split-wx=on|off Controls the use of split w^x mapping for the TCG code generation buffer. Some operating systems require this to be enabled, and in such a case this will default on. On other operating systems, this will default off, but one may enable this for testing or debugging.
- tb-size=n Controls the size (in MiB) of the TCG translation block cache.
- thread=single|multi Controls number of TCG threads. When the TCG is multi-threaded there will be one thread per vCPU therefore taking advantage of additional host cores. The default is to enable multi-threading where both the back-end and front-ends support it and no incompatible TCG features have been enabled (e.g. icount/replay).
- dirty-ring-size=n When the KVM accelerator is used, it controls the size of the per-vCPU dirty page ring buffer (number of entries for each vCPU). It should be a value that is power of two, and it should be 1024 or bigger (but still less than the maximum value that the kernel supports). 4096 could be a good initial value if you have no idea which is the best. Set this value to 0 to disable the feature. By default, this feature is disabled (dirty-ring-size=0). When enabled, KVM will instead record dirty pages in a bitmap.

`smp [[cpus=]n][,maxcpus=maxcpus][,sockets=sockets][,dies=dies][,cores=cores][,threads=threads]`

功能配置客户机的 SMP（Symmetric Multi-Processing），对称多处理机
子参数
- [cpus=]n 设置客户机中使用逻辑的 CPU 数量（默认值是 1）。
- [,maxcpus=cpus] 设置客户机最大可能被使用的 CPU 数量（可以用热插拔 hot-plug 添加 CPU，不能超过 maxcpus 上限）。
- [,cores=cores] 设置每个 CPU socket 上的 core 数量（默认值是 1）。
- [,threads=threads] 设置每个 CPU core 上的线程数（默认值是 1）。
- [,sockets=sockets] 设置客户机中总的 CPU socket 数量。
调用实例

qemu-system-x86_64  -smp 1,sockets=1,cores=2,threads=2

`-numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]`

`-numa node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]`

`-numa dist,src=source,dst=destination,val=distance`

`-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]`

`-numa hmat-lb,initiator=node,target=node,hierarchy=hierarchy,data-type=tpye[,latency=lat][,bandwidth=bw]`

`-numa hmat-cache,node-id=node,size=size,level=level[,associativity=str][,policy=str][,line=size]`

功能
子参数
调用实例

`-add-fd fd=fd,set=set[,opaque=opaque]`

功能
子参数
调用实例

`-set group.id.arg=value`

功能
子参数
调用实例

`-global driver.prop=value`

功能
子参数
调用实例

`-global driver=driver,property=property,value=value`

功能
子参数
调用实例

`-boot [order=drives][,once=drives][,menu=on|off][,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_timeout][,strict=on|off]`

功能设置客户机启动顺序

在 qemu 模拟的 x86 平台中，用"a"、“b"分别表示第一和第二软驱，用"c"表示第一个硬盘，用"d"表示 CD-ROM 光驱，用"n"表示从网络启动。默认从硬盘启动。

子参数
- [order=drives] 设置启动顺序。
- [,once=drives] 只设置下一次启动的顺序，再重启后无效。
- [,menu=on|off] 只要固件/BIOS 支持，就可以启用交互式引导菜单/提示。默认为非交互式引导。
- [,splash=sp_name] 如果固件/BIOS 支持选项 splash=sp_name 和 menu=on，则可以将启动画面传递给 bios，使用户能够将其显示为徽标。目前 Seabios for X86 系统支持它。限制：启动文件可以是 24 BPP 格式（真彩色）的 jpeg 文件或 BMP 文件。分辨率应该是 SVGA 模式支持的，推荐 320x240、640x480、800x640。
- [,splash-time=sp_time]
- [,reboot-timeout=rb_timeout] 引导失败时，客户机将暂停 rb_timeout 毫秒，然后重新启动。如果 rb_timeout 为 ‘-1’，客户机不会重启，qemu 默认将 ‘-1’ 传递给 bios。目前 Seabios for X86 系统支持它。
- [,strict=on|off] 只要固件/BIOS 支持，就通过严格启动。这仅在 bootindex 选项更改引导优先级时有效。默认为非严格引导。

调用实例

# 尝试先从网络启动，然后从硬盘启动
qemu-system-x86_64 -boot order=nc
# 先从光驱启动，重启后切换回默认顺序
qemu-system-x86_64 -boot once=d
# 5 秒钟的启动画面。
qemu-system-x86_64 -boot menu=on,splash=/root/boot.bmp,splash-time=5000

`-m [size=]megs[,slots=n,maxmem=size]`

功能将客户机内存设置为 megs M字节。默认值为 128 MiB。或者，也可以使用“M”或“G”的后缀。齐。
子参数
- [size=]megs 将客户机内存设置为 megs M字节
- [,slots=n,maxmem=size] 可用于设置可热插拔内存插槽的数量和最大内存数量。maxmem 必须与页面大小对
调用实例以下命令行将客户机启动 RAM 大小设置为 1GB，创建 3 个插槽以热插拔额外内存，并将客户机可以达到的最大内存设置为 4GB：
```
qemu-system-x86_64 -m 1G,slots=3,maxmem=4G
```
如果未指定 slot 和 maxmem，则不会启用内存热插拔，并且客户机内存永远不会增加。

`-mem-path path`

功能使用huge page。对于内存访问密集型的应用，使用huge page是可以比较明显地提高客户机性能。使用huge page的内存不能被换出（swap out），也不能使用ballooning方式自动增长。
子参数
调用实例

`-mem-prealloc`

功能使宿主机在客户机启动时就全部分配好客户机的内存
子参数
调用实例

`-k language`

功能设置键盘布局语言，默认为en-us

子参数可用布局：

ar  de-ch  es  fo     fr-ca  hu  ja  mk     no  pt-br  sv
da  en-gb  et  fr     fr-ch  is  lt  nl     pl  ru     th
de  en-us  fi  fr-be  hr     it  lv  nl-be  pt  sl     tr

调用实例

块设备参数 Block device options

`fda file`

功能为客户机指定软盘设备，指定客户机的第一个软盘设备，在客户机中显示为/dev/fd0
子参数
调用实例

`fdb file`

功能为客户机指定软盘设备，指定客户机的第一个软盘设备，在客户机中显示为/dev/fd1
子参数
调用实例

`hda file`

`hdb file`

`hdc file`

`hdd file`

功能为客户机指定块存储设备，指定客户机种的第一个 IDE 设备
子参数若客户机使用PIIX_IDE驱动，显示为/dev/hda设备；若客户机使用ata_piix驱动，显示为/dev/sda设备。若没有使用-hdx的参数，则默认使用-hda参数；可以将宿主机的一块硬盘作为-hda的参数使用；若文件名包含逗号，应使用两个连续的逗号进行转义。
调用实例

`-cdrom file`

功能为客户机指定光盘 CD-ROM。可以将宿主机的光驱/dev/cdrom设备作为-cdrom参数使用。-cdrom参数不能与-hdc参数同时使用，因为-cdrom就是客户机里的第三个 IDE 设备
子参数
调用实例

`-blockdev option[,option[,option[,...]]]`

功能
子参数
调用实例

`-drive option[,option[,option[,...]]]`

功能定义一个存储驱动器
子参数
- [file=file] 加载file镜像文件到客户机的驱动器中。
- [,if=type] 指定驱动器使用的接口类型：可用的类类型有：ide、scsi、virtio、sd、floopy、pflash等。
- [,bus=n] 设置驱动器在客户机中的总线编号。
- [,unit=m] 设置驱动器在客户机中的单元编号。
- [,media=d] 设置驱动器中媒介的类型，值为 disk 或 cdrom。
- [,index=i] 设置在通一种接口的驱动器中的索引编号。
- [,snapshot=on|off] 当值为 on 时，qemu 不会将磁盘数据的更改写回到镜像文件中，而是写到临时文件中，可以在 qemu moinitor 中使用 commit 命令强制将磁盘数据保存回镜像文件中。
- [,cache=writethrough|writeback|none|directsync|unsafe] 设置宿主机对块设备数据访问的 cache 模式。， writethrough（直写模式）：调用 write 写入数据的同时将数据写入磁盘缓存和后端块设备中。 writeback（回写模式）：调用 write 写入数据时只将数据写入到磁盘缓存中，当数据被换出缓存时才写入到后端存储中。优点写入数据块，缺点系统掉电数据无法恢复。
- [,aio=threads|native] 选择异步 IO 的方式
- threads 为 aio 参数的默认值，让一个线程池去处理异步 IO；
- native 只适用于 cache=none 的情况，使用的是 Linux 原生的 AIO。
- [,format=f] 指定使用的磁盘格式，默认是 QEMU 自动检测磁盘格式的。
- [,serial=s] 指定分配给设备的序列号。
- [,addr=A] 分配给驱动器控制器的 PCI 地址，只在使用 virtio 接口时适用。
- [,id=name] 设置驱动器的 ID，可以在 QEMU monitor 中用 info block 看到。 [,readonly=on|off] 设置驱动器是否只读。
调用实例

USB 参数 USB convenience options

显示参数 Display options

仅限 i386 架构的参数 i386 target only

网络参数 Network options

字符设备参数 Character device options

TPM 设备 TPM device options

指定启动指引 Linux/Multiboot boot specific

当使用该调用参数时，你可以使用给定的 Linux 或者多重引导内核，而不需要安装内核到一个光盘中。这样可以更方便地测试不同内核。

-kernel bzImage
- 功能用 bzImage 作为内核镜像，也可以使用其他启动格式。
-append cmdline
- 功能用cmd命令行，作为内核的命令行
-initrd file
- 功能用文件作为初始化 ram
-initrd "file1 arg=foo,file2"
- 功能此语法仅适用于多重引导使用 file1 和 file2 作为模块并将 arg=foo 作为参数传递给第一个模块
-dtb file
- 功能将文件用作设备树二进制 (dtb) 映像并在启动时将其传递给内核

QEMU 初识

Fri, 23 Jul 2021 11:54:49 +0000

简介

QEMU 是一款开源的模拟器及虚拟机监管器 (Virtual Machine Monitor, VMM)。QEMU 主要提供两种功能给用户使用。一是作为用户态模拟器，利用动态代码翻译机制来执行不同于主机架构的代码。二是作为虚拟机监管器，模拟全系统，利用其他 VMM(Xen, KVM, etc) 来使用硬件提供的虚拟化支持，创建接近于主机性能的虚拟机。

安装

使用包管理安装

sudo apt-get install qemu

使用源码安装

wget wget https://download.qemu.org/qemu-6.1.0-rc3.tar.xz
tar xvJf qemu-6.1.0-rc3.tar.xz
cd qemu-6.1.0-rc3

安装相关库

apt-get install libglib2.0-dev
apt-get install ninja-build
apt install g++
apt install libpixman-1-dev
apt install libsdl2-dev -y

配置

通过./configure --help 的查看编译时的选项，--target-list选项为可选的模拟器，默认全选。 --target-list 中的 xxx-soft 和 xxx-linux-user 分别指系统模拟器和应用程序模拟器，生成的二进制文件名字为qemu-system-xxx和 qemu-xxx 本文使用如下配置：

./configure --prefix=XXX --enable-debug --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-linux-user,riscv64-softmmu --enable-kvm
# --prefix 选项设置qemu的安装位置绝对路径，之后若要卸载删除qemu只要删除该文件夹即可，--enable-kvm开启kvm
# config完，可以在指定的qemu安装文件夹下面找到config-host.mak文件，
# 该文件记录着qemu配置的选项，可以和自己设置的进行对比，确保配置和自己已知

接着进行编译

make -j8

直接make会很慢，第一次编译时默认安装说有模拟器，编译了三四个小时。加上-j8可以进行多线程编译

创建与使用

创建虚拟镜像

使用虚拟镜像来模拟虚拟机的硬盘，在启动虚拟机之前需要创建一个镜像文件

root@hanhan:/home/dominic/qemu/# qemu-img create -f qcow2 qmtest.img 10G
Formatting 'qmtest.img', fmt=qcow2 size=10737418240 encryption=off cluster_size=65536 lazy_refcounts=off 
root@hanhan:/home/dominic/qemu/# ls
qmtest.img

-f选项用于指定镜像的格式，qcow2格式是 QEMU 最常用的镜像格式，采用写时复制技术来优化性能。qmtest.img是镜像文件的名字，10G是镜像文件大小。

镜像文件创建完成后，可使用qemu-system-x86来启动x86架构的虚拟机：

qemu-system-x86_64 qmtest.img

qmtest.img 中还未安装操作系统，所以会提示“No bootable device”的错误。

准备操作系统镜像

下载需要的 Linux 发行版镜像文件，https://launchpad.net/ubuntu/+cdmirrors，找到想要下载的镜像，这里以交通大学的镜像为例右击链接复制地址：https://ftp.sjtu.edu.cn/ubuntu-cd/20.10/ubuntu-20.10-live-server-amd64.iso

root@hanhan:/home/dominic/qemu/# wget https://ftp.sjtu.edu.cn/ubuntu-cd/20.10/ubuntu-20.10-live-server-amd64.iso

检查 KVM 是否可用

QEMU 使用 KVM 来提升虚拟机性能，如果不启用 KVM 会导致性能损失。要使用 KVM，首先要检查硬件是否有虚拟化支持：

root@hanhan:/home/dominic/qemu/# grep -E 'vmx|svm' /proc/cpuinfo

如果有输出则表示硬件有虚拟化支持。其次要检查 kvm 模块是否已经加载：

root@hanhan:/home/dominic/qemu/# lsmod | grep kvm
kvm_intel             142999  0 
kvm                   444314  1 kvm_intel

如果kvm_intel/kvm_amd、kvm模块被显示出来，则kvm模块已经加载。最后要确保 qemu 在编译的时候使能了KVM，即在执行configure脚本的时候加入了–enable-kvm选项。

启动虚拟机安装操作系统

root@hanhan:/home/dominic/qemu/# qemu-system-x86_64 -m 2048 -enable-kvm qmtest.img -cdrom ./Fedora-Live-Desktop-x86_64-20-1.iso

-m指定虚拟机内存大小，默认单位是 MB，-enable-kvm使用 KVM 进行加速，-cdrom添加 fedora 的安装镜像。可在弹出的窗口中操作虚拟机，安装操作系统，安装完成后重起虚拟机便会从硬盘 (qmtest.img) 启动。之后再启动虚拟机只需要执行：

root@hanhan:/home/dominic/qemu/#  qemu-system-x86_64 -m 2048 -enable-kvm qmtest.img

退出 qemu

在运行 qemu 后，关闭图形界面但是终端仍然是处于 qemu 环境中，可以直接关闭终端退出。如果不想关闭终端，可以另外打开一个终端 kill 进程

killall qemu-system-riscv32

如果记不清全称，可以输入大概名称回车后会列出相关的进程

QEMU 学习记录

Tue, 20 Jul 2021 16:51:34 +0000

QEMU 学习记录

什么是 KVM？

基于内核的虚拟机 Kernel-based Virtual Machine（KVM）是一种内建于 Linux 中的开源虚拟化技术。具体而言，KVM 可帮助用户将 Linux 转变为虚拟机监控程序，使主机计算机能够运行多个隔离的虚拟环境，即虚拟客户机或虚拟机（VM）。

什么是 QEMU？

Qemu 是一个完整的可以单独运行的软件，它可以用来模拟不同架构的机器，非常灵活和可移植。它主要通过一个特殊的’重编译器’将为特定处理器编写二进制代码转换为另一种。

KVM 与 QEMU 的关系

KVM 是 Linux 的一个模块。可以用modprobe去加载 KVM 模块。加载了模块后，才能进一步通过其他工具创建虚拟机。但仅有 KVM 模块是远远不够的，因为用户无法直接控制内核模块去作事情：还必须有一个用户空间的工具才行。这个用户空间的工具，开发者选择了已经成型的开源虚拟化软件 QEMU。KVM 使用了 QEMU 的一部分，并稍加改造，就成了可控制 KVM 的用户空间工具了。所以你会看到，官方提供的 KVM 下载有两大部分三个文件，分别是 KVM 模块、QEMU 工具以及二者的合集。也就是说，你可以只升级 KVM 模块，也可以只升级 QEMU 工具。

QEMU 用户模式与系统模式

QEMU 属于应用层的仿真程序，它支持两种操作模式：用户模式模拟和系统模式模拟。

用户模式仿真 利用动态代码翻译机制，可以在当前 CPU 上执行被编译为支持其他 CPU 的程序，如可以在 x86 机器上执行一个 ARM 二进制可执行程序。（执行主机 CPU 指令的动态翻译并相应地转换 Linux 系统调用）。
系统模式仿真 利用其它 VMM(Xen, KVM) 来使用硬件提供的虚拟化支持，创建接近于主机性能的全功能虚拟机，包括处理器和配套的外围设备（磁盘，以太网等）。

用户模式

支持的 CPU：x86 (32 and 64 bit), PowerPC (32 and 64 bit), ARM, MIPS (32 bit only), Sparc (32 and 64 bit), Alpha, ColdFire(m68k), CRISv32 和 MicroBlaze 下列操作系统支持 QEMU 的用户模式模拟：

Linux (referred as qemu-linux-user)
BSD (referred as qemu-bsd-user)

调用（具体参数含义）

qemu-i386 [-h] [-d] [-L path] [-s size] [-cpu model] [-g port] [-B offset] [-R size] program [arguments...]

用户模式模拟环境下运行速度要比系统模式模拟环境下快，但并不是完美模拟，比如程序读取/proc/cpuinfo内容时，由主机内核返回，因此返回的信息是描述主机 CPU 的，而不是模拟的 CPU。

系统模式

首先创建虚拟镜像，模拟硬盘空间：

root@hanhan:/home/dominic/qemu/# qemu-img create -f qcow2 qmtest.img 10G
Formatting 'qmtest.img', fmt=qcow2 size=10737418240 encryption=off cluster_size=65536 lazy_refcounts=off 
root@hanhan:/home/dominic/qemu/# ls
qmtest.img

-f选项用于指定镜像的格式，qcow2格式是 QEMU 最常用的镜像格式，采用写时复制技术来优化性能。qmtest.img是镜像文件的名字，10G是镜像文件大小。

镜像文件创建完成后，可使用qemu-system-x86来启动x86架构的虚拟机：

qemu-system-x86_64 qmtest.img

qmtest.img 中还未安装操作系统，所以会提示“No bootable device”的错误。

其次，准备操作系统镜像下载需要的 Linux 发行版镜像文件，https://launchpad.net/ubuntu/+cdmirrors，找到想要下载的镜像，这里以交通大学的镜像为例右击链接复制地址：https://ftp.sjtu.edu.cn/ubuntu-cd/20.10/ubuntu-20.10-live-server-amd64.iso

root@hanhan:/home/dominic/qemu/# wget https://ftp.sjtu.edu.cn/ubuntu-cd/20.10/ubuntu-20.10-live-server-amd64.iso

最后，启动虚拟机安装操作系统

root@hanhan:/home/dominic/qemu/# qemu-system-x86_64 -m 2048 -enable-kvm qmtest.img -cdrom ./Fedora-Live-Desktop-x86_64-20-1.iso

-m指定虚拟机内存大小，默认单位是 MB，-enable-kvm使用 KVM 进行加速，-cdrom添加 fedora 的安装镜像。

该模式下，要比用户模式模拟慢得多，因为模拟了目标内核，以及设备输入/输出、中断等。

QEMU 工作原理

Responsive Image

单纯使用 qemu，采用的是完全虚拟化的模式。qemu 向 Guest OS 模拟 CPU，也模拟其他的硬件，GuestOS 认为自己和硬件直接打交道，其实是同 qemu 模拟出来的硬件打交道，qemu 会将这些指令转译给真正的硬件。由于所有的指令都要从 qemu 里面过一手，因而性能就会比较差。

完全虚拟化是非常慢的，所以要使用硬件辅助虚拟化技术 Intel-VT，AMD-V，所以需要 CPU 硬件开启这个标志位，一般在 BIOS 里面设置。当确认开始了标志位之后，通过KVM，GuestOS 的 CPU 指令不用经过 Qemu 转译，直接运行，大大提高了速度。所以，KVM 在内核里面需要有一个模块，来设置当前 CPU 是 Guest OS 在用，还是 Host OS 在用。

可以通过如下命令查看内核模块中是否有 KVM

lsmod | grep kvm

KVM 内核模块通过 /dev/kvm 暴露接口，用户态程序可以通过 ioctl来访问这个接口。Qemu 将 KVM 整合进来，将有关 CPU 指令的部分交由内核模块来做，就是 qemu-kvm (qemu-system-XXX)。

qemu 和 kvm 整合之后，CPU 的性能问题解决了。另外 Qemu 还会模拟其他的硬件，如网络和硬盘。同样，全虚拟化的方式也会影响这些设备的性能。

于是，qemu 采取半虚拟化的方式，让 Guest OS 加载特殊的驱动来做这件事情。

例如，网络需要加载 virtio_net，存储需要加载 virtio_blk，Guest 需要安装这些半虚拟化驱动，GuestOS 知道自己是虚拟机，所以数据会直接发送给半虚拟化设备，经过特殊处理（例如排队、缓存、批量处理等性能优化方式），最终发送给真正的硬件。这在一定程度上提高了性能。

Q : 系统模式和用户模式的区别？系统模式是 qemu 虚拟出一套完整的硬件环境，包含 CPU，内存，网卡，硬盘，对于虚拟机上运行的 OS 看到的和硬件和真实的是一样的。用户模式是直接将可执行的文件进行指令翻译，只虚拟出 CPU。假设有 KVM：host 是 x86，QEMU 虚拟出 x86 的系统模式运行 Windows 系统。QEMU 会将 Windows 指令直接交给 host CPU 直接运行（这个功能是由 KVM 实现的，相当于直接调用 host CPU），性能损失小。内存，硬盘，网络等外设是由 qemu 虚拟出来的。假设无 KVM：host 是 x86，QEMU 虚拟出 x86 的系统模式运行 Windows 系统。QEMU 会将 Windows 指令翻译成中间码，中间码再转成 host CPU 指令（这个功能是由 qemu TCG 实现的），性能损失大。内存，硬盘，网洛等外设是由 qemu 虚拟出来的。假设有 KVM：host 是 x86，QEMU 虚拟出 RISC-V 的系统模式运行 Linux 系统。QEMU 会将 Linux 指令翻译成中间码，中间码再转成 host CPU 指令（这个功能是由 qemu TCG 实现的），性能损失大。内存，硬盘，网洛等外设是由 qemu 虚拟出来的。 KVM 需要在虚拟机与宿主机架构相同时才生效。此外，用户模式下调用 IO 硬件会报错。qemu 系统模式下会模拟出所有设备，但是模拟的 IO 设备效率低，所以后来有了半虚拟化。