問題1：支持ARMv8的Linux內(nèi)核異常向量地址在哪？

答：異常向量基地址在0xffffffc000081800。通過查看編譯后的linux內(nèi)核的System.map文件，能確定異常向量表的基地址。通過反匯編生成的支持armv8的linux內(nèi)核也可以證實。Armv8的異常向量表的定義在內(nèi)核的arch/arm/kernel/entry.S中，將其摘錄如下：

/*

 * Exception vectors.

 */

        .macro ventry  label

        .align 7

        b      label

        .endm

        .align 11

ENTRY(vectors)                                                                   

        ventry el1_sync_invalid                //Synchronous EL1t

        ventry el1_irq_invalid                 //IRQ EL1t

        ventry el1_fiq_invalid                 //FIQ EL1t

        ventry el1_error_invalid               //Error EL1t

        ventry el1_sync                        //Synchronous EL1h

        ventry el1_irq                         //IRQ EL1h

        ventry el1_fiq_invalid                 //FIQ EL1h

        ventry el1_error_invalid               //Error EL1h

        ventry el0_sync                        //Synchronous 64-bit EL0

        ventry el0_irq                         //IRQ 64-bit EL0

        ventry el0_fiq_invalid                 //FIQ 64-bit EL0

        ventry el0_error_invalid               //Error 64-bit EL0

#ifdefCONFIG_AARCH32_EMULATION

        ventry el0_sync_compat                 //Synchronous 32-bit EL0

        ventry el0_irq_compat                  //IRQ 32-bit EL0

        ventry el0_fiq_invalid_compat          //FIQ 32-bit EL0

        ventry el0_error_invalid_compat        //Error 32-bit EL0

#else

        ventry el0_sync_invalid                //Synchronous 32-bit EL0

        ventry el0_irq_invalid                 //IRQ 32-bit EL0

        ventry el0_fiq_invalid                 //FIQ 32-bit EL0

        ventry el0_error_invalid               //Error 32-bit EL0

#endif

END(vectors)

問題2：找出TLB中存放的ARMv8的頁表格式

答：只找到了頁表的格式。TLB中的格式?jīng)]找到。

ARMv8支持4KB頁大小的4級頁表轉(zhuǎn)換到64KB頁大小的3級頁表轉(zhuǎn)換。

以下是從內(nèi)核源碼的Documentation找到的信息。

AArch64 Linux memory layout:

Start                          End                    Size           Use

-----------------------------------------------------------------------

0000000000000000        0000007fffffffff      512GB            user

ffffff8000000000    ffffffbbfffeffff         ~240GB            vmalloc

ffffffbbffff0000       ffffffbcffffffff   64KB             [guardpage]

ffffffbc00000000    ffffffbdffffffff    8GB            vmemmap

ffffffbe00000000    ffffffbffbffffff   ~8GB            [guard,future vmmemap]

ffffffbffc000000     ffffffbfffffffff    64MB           modules

ffffffc000000000    ffffffffffffffff  256GB            memory

Translation table lookup with 4KB pages:

+--------+--------+--------+--------+--------+--------+--------+--------+

|63   56|55    48|47    40|39   32|31    24|23    16|15    8|7      0|

+--------+--------+--------+--------+--------+--------+--------+--------+

 |                 |         |         |         |         |

 |                 |         |         |         |         v

 |                 |         |         |         |  [11:0]  in-page offset

 |                 |         |         |         +-> [20:12] L3 index

 |                 |         |         +-----------> [29:21] L2 index

 |                 |         +---------------------> [38:30] L1index

 |                +------------------------------->[47:39] L0 index (not used)

 +------------------------------------------------->[63] TTBR0/1

Translation table lookup with 64KB pages:

+--------+--------+--------+--------+--------+--------+--------+--------+

|63   56|55    48|47    40|39   32|31    24|23    16|15    8|7      0|

+--------+--------+--------+--------+--------+--------+--------+--------+

 |                 |    |               |              |

 |                 |    |               |              v

 |                 |    |               |            [15:0]  in-page offset

 |                 |    |               +----------> [28:16] L3 index

 |                 |    +--------------------------> [41:29] L2index (only 38:29 used)

 |                +-------------------------------> [47:42] L1 index (not used)

 +------------------------------------------------->[63] TTBR0/1

問題3：ARMv8中重要的控制寄存器的各位的意思是什么？

答：源碼中沒找到對ARMv8控制寄存器的詳細(xì)描述。

1.     關(guān)于SPSR，該寄存器是CPSR的副本，當(dāng)在不同模式間轉(zhuǎn)換時，該寄存器保存CPSR的內(nèi)容，用于狀態(tài)恢復(fù)。

在arch/arm64/include/asm/ptrace.h中找到AArch64的spsr寄存器某些位的定義，經(jīng)過與ARMv7的對比發(fā)現(xiàn)，以下定義的位于ARMv7中定義的位意義相同。

/*AArch64 SPSR bits */

#definePSR_F_BIT  0x00000040

#definePSR_I_BIT   0x00000080

#definePSR_A_BIT  0x00000100

#definePSR_D_BIT  0x00000200

#definePSR_Q_BIT 0x08000000

#definePSR_V_BIT  0x10000000

#definePSR_C_BIT  0x20000000

#definePSR_Z_BIT  0x40000000

#define PSR_N_BIT 0x80000000

2.     ARMv8中的系統(tǒng)控制寄存器有多個，但與ARMv7不同的是：ARMv8中拋棄了“協(xié)處理器”的概念，進(jìn)而就沒了MCR，MRC類的指令，見參考資料[3]，其系統(tǒng)控制都是通過MSR，MRS類指令進(jìn)行。通過閱讀Linux內(nèi)核源碼發(fā)現(xiàn)，主要的控制寄存器有：

hcr_el2:el2中的hypervisor配置寄存器

cnthctl_el2：可配置通用時鐘

另外還有，vmpidr_el2；vpidr_el2；sctlr_el1：cptr_el2；hstr_el2；spsr_el2；vbar_el1；ttbr0_el1；ttbr1_el1；sctlr_el1

參考資料

[1] ARMv8的編譯器binutils，結(jié)構(gòu)體aarch64_opcode_table定義見line 1208

http://kernel.ubuntu.com/git?p=jk/arm64/binutils.git;a=blob;f=opcodes/aarch64-tbl.h;h=d360b1406718257da86050f5b3a760cd02196250;hb=aarch64

[2] 結(jié)構(gòu)體aarch64_opcode定義，line451

http://kernel.ubuntu.com/git?p=jk/arm64/binutils.git;a=blob;f=include/opcode/aarch64.h;h=98529954ea098349eb16572d4915f4edbd2e7b5d;hb=aarch64

[3] 《ARMv8 InstructionSet Overview 》page11