RISC-V特权架构手册Vol. II：最新1.12版

需积分: 11 108 浏览量更新于2024-07-09 收藏 690KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

RISC-V指令集手册第二卷：特权架构文档版本1.12草案，由Andrew Waterman、Krste Asanović和John Hauser联合编撰，来自SiFive公司和加州大学伯克利分校的计算机科学系。这本手册详细阐述了RISC-V（精简指令集计算机）架构的核心特性，特别是其特权模式下的指令集设计，这是RISC-V体系结构的重要组成部分。 RISC-V是一种开放源代码的CPU架构，它旨在提供可扩展性和灵活性，以适应现代硬件的需求。与ARM等传统架构相比，RISC-V强调简洁的指令集，减少了复杂性，从而提高执行效率。该手册涵盖了特权架构的各个方面，包括但不限于： 1. **特权模式**：RISC-V提供了多种特权级别，如用户模式、监督模式和机器模式，这些模式决定了程序可以访问的硬件资源和执行的操作权限。了解这些模式有助于开发人员在安全性和性能之间找到平衡。 2. **指令集指令**：文档详细介绍了RISC-V的ISA（指令集架构），包括基础的算术运算、逻辑运算、控制转移指令以及高级功能如内存访问和异常处理。理解这些指令是编写RISC-V程序的基础。 3. **寄存器文件**：手册解释了RISC-V中的通用寄存器和特殊功能寄存器（如PC、SP等）的作用，这对于程序性能优化至关重要。 4. **异常处理**：RISC-V支持异常处理机制，用于处理中断和错误情况，确保系统的健壮性。这部分内容涵盖了异常向量表、异常处理程序和异常返回路径等关键概念。 5. **内存管理**：手册涉及内存管理单元（MMU）的实现，以及虚拟地址到物理地址的转换，这对于系统级编程和操作系统设计尤为重要。 6. **安全性**：虽然没有明确提及，但作为特权架构的一部分，RISC-V可能包含了对安全特性的支持，例如权限检查和隔离，以保护敏感操作。 7. **贡献者名单**：文档列出了一长串对RISC-V发展做出贡献的专家，他们的工作共同塑造了RISC-V的不断完善。通过阅读这份RISC-V指令集手册第二卷，开发人员可以深入理解RISC-V架构的工作原理，为设计和实现基于RISC-V的SoC（片上系统）和CPU提供坚实的理论基础。无论是嵌入式系统开发者、操作系统构建者还是硬件工程师，掌握这份文档都将对他们的工作有显著的帮助。

资源详情

资源推荐

2 Volume II: RISC-V Privileged Architectures V1.12-draft

Application

ABI

AEE

Application

ABI

SBI

SEE

Application

ABI

SBI

Hypervisor

Application

ABI

Application

ABI

Application

ABI

Application

ABI

SBI

HBI

HEE

Figure 1.1: Diﬀerent implementation stacks supporting various forms of privileged execution.

The middle conﬁguration shows a conventional operating system (OS) that can support multipro-

grammed execution of multiple applications. Each application communicates over an ABI with

the OS, which provides the AEE. Just as applications interface with an AEE via an ABI, RISC-V

operating systems interface with a supervisor execution environment (SEE) via a supervisor binary

interface (SBI). An SBI comprises the user-level and supervisor-level ISA together with a set of

SBI function calls. Using a single SBI across all SEE implementations allows a single OS binary

image to run on any SEE. The SEE can be a simple boot loader and BIOS-style IO system in a

low-end hardware platform, or a hypervisor-provided virtual machine in a high-end server, or a

thin translation layer over a host operating system in an architecture simulation environment.

Most supervisor-level ISA deﬁnitions do not separate the SBI from the execution environment

and/or the hardware platform, complicating virtualization and bring-up of new hardware plat-

forms.

The rightmost conﬁguration shows a virtual machine monitor conﬁguration where multiple multi-

programmed OSs are supported by a single hypervisor. Each OS communicates via an SBI with

the hypervisor, which provides the SEE. The hypervisor communicates with the hypervisor execu-

tion environment (HEE) using a hypervisor binary interface (HBI), to isolate the hypervisor from

details of the hardware platform.

The ABI, SBI, and HBI are still a work-in-progress, but we are now prioritizing support for

Type-2 hypervisors where the SBI is provided recursively by an S-mode OS.

Hardware implementations of the RISC-V ISA will generally require additional features beyond the

privileged ISA to support the various execution environments (AEE, SEE, or HEE).

1.2 Privilege Levels

At any time, a RISC-V hardware thread (hart) is running at some privilege level encoded as a mode

in one or more CSRs (control and status registers). Three RISC-V privilege levels are currently

deﬁned as shown in Table 1.1.

Privilege levels are used to provide protection between diﬀerent components of the software stack,

and attempts to perform operations not permitted by the current privilege mode will cause an

Volume II: RISC-V Privileged Architectures V1.12-draft 3

Level Encoding Name Abbreviation

0 00 User/Application U

1 01 Supervisor S

2 10 Reserved

3 11 Machine M

Table 1.1: RISC-V privilege levels.

exception to be raised. These exceptions will normally cause traps into an underlying execution

environment.

In the description, we try to separate the privilege level for which code is written, from the

privilege mode in which it runs, although the two are often tied. For example, a supervisor-

level operating system can run in supervisor-mode on a system with three privilege modes, but

can also run in user-mode under a classic virtual machine monitor on systems with two or

more privilege modes. In both cases, the same supervisor-level operating system binary code can

be used, coded to a supervisor-level SBI and hence expecting to be able to use supervisor-level

privileged instructions and CSRs. When running a guest OS in user mode, all supervisor-level

actions will be trapped and emulated by the SEE running in the higher-privilege level.

The machine level has the highest privileges and is the only mandatory privilege level for a RISC-V

hardware platform. Code run in machine-mode (M-mode) is usually inherently trusted, as it has

low-level access to the machine implementation. M-mode can be used to manage secure execution

environments on RISC-V. User-mode (U-mode) and supervisor-mode (S-mode) are intended for

conventional application and operating system usage respectively.

Each privilege level has a core set of privileged ISA extensions with optional extensions and variants.

For example, machine-mode supports an optional standard extension for memory protection. Also,

supervisor mode can be extended to support Type-2 hypervisor execution as described in Chapter 5.

Implementations might provide anywhere from 1 to 3 privilege modes trading oﬀ reduced isolation

for lower implementation cost, as shown in Table 1.2.

Number of levels Supported Modes Intended Usage

1 M Simple embedded systems

2 M, U Secure embedded systems

3 M, S, U Systems running Unix-like operating systems

Table 1.2: Supported combinations of privilege modes.

All hardware implementations must provide M-mode, as this is the only mode that has unfettered

access to the whole machine. The simplest RISC-V implementations may provide only M-mode,

though this will provide no protection against incorrect or malicious application code.

The lock feature of the optional PMP facility can provide some limited protection even with only

M-mode implemented.

Chapter 2

Control and Status Registers (CSRs)

The SYSTEM major opcode is used to encode all privileged instructions in the RISC-V ISA. These

can be divided into two main classes: those that atomically read-modify-write control and status

registers (CSRs), which are deﬁned in the Zicsr extension, and all other privileged instructions.

The privileged architecture requires the Zicsr extension; which other privileged instructions are

required depends on the privileged-architecture feature set.

In addition to the user-level state described in Volume I of this manual, an implementation may

contain additional CSRs, accessible by some subset of the privilege levels using the CSR instructions

described in the user-level manual. In this chapter, we map out the CSR address space. The

following chapters describe the function of each of the CSRs according to privilege level, as well as

the other privileged instructions which are generally closely associated with a particular privilege

level. Note that although CSRs and instructions are associated with one privilege level, they are

also accessible at all higher privilege levels.

2.1 CSR Address Mapping Conventions

The standard RISC-V ISA sets aside a 12-bit encoding space (csr[11:0]) for up to 4,096 CSRs.

By convention, the upper 4 bits of the CSR address (csr[11:8]) are used to encode the read and

write accessibility of the CSRs according to privilege level as shown in Table 2.1. The top two bits

(csr[11:10]) indicate whether the register is read/write (00, 01, or 10) or read-only (11). The next

two bits (csr[9:8]) encode the lowest privilege level that can access the CSR.

The CSR address convention uses the upper bits of the CSR address to encode default access

privileges. This simpliﬁes error checking in the hardware and provides a larger CSR space, but

does constrain the mapping of CSRs into the address space.

Implementations might allow a more-privileged level to trap otherwise permitted CSR ac-

cesses by a less-privileged level to allow these accesses to be intercepted. This change should be

transparent to the less-privileged software.

Attempts to access a non-existent CSR raise an illegal instruction exception. Attempts to access a

CSR without appropriate privilege level or to write a read-only register also raise illegal instruction

剩余134页未读，继续阅读

nj_dobetter

粉丝: 79
资源: 25

RISC-V特权架构手册Vol. II：最新1.12版

The RISC-V Instruction Set Manual Volume I-Unprivileged ISA V20180801-draft

The RISC-V Instruction Set Manual Volume II: Privileged Architecture 1.10

The RISC-V Instruction Set Manual:Volume I: User-Level ISA Document Version 2.2

推荐一些RISC-V相关的书籍

RISC-V的学习路线

the risc-v reader 中文pdf

RISC-V的软件需求有哪些，RISC-V虚拟化需要那些知识，RISC-V的软件生态要做哪些

计算机组成与设计 硬/软件接口 risc-v pdf

验证risc-v处理器跟risc-v处理器内核有什么不同吗

RISC-v学习手册

RISC-V汇编语言开发工具

risc-v-reader-chinese-v2.3

risc-v verilog

risc-v 架构手册

risc-v reader 中文版

推荐一些RISC-V相关的中文书籍

risc-v 指令集 中文

risc-v aclint

risc-v 规范中文

risc-v架构与嵌入式开发快速入门 pdf下载

最新资源

计算机组成与设计硬/软件接口 risc-v pdf

risc-v 指令集中文