RISC-V特权架构手册：2019年6月8日发布，操作系统与设备支持详解

RISC-V

需积分: 10 140 浏览量更新于2024-07-16 收藏 521KB PDF 举报

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

领优惠券(最高得80元）

RISC-V-privileged-20190608-1.pdf文档详细阐述了RISC-V特权架构，这是对未经特权指令集架构（ISA）扩展的部分，它涵盖了操作系统运行和外部设备连接所需的各个方面。该架构专为RISC-V系统设计，提供了一套高级功能，以支持更复杂的系统管理任务。在RISC-V体系结构中，特权部分是与基础无特权指令集相对应的高级层次。它包括一系列特殊指令，这些指令只有在系统处于特定权限级别时才能执行，如操作系统内核或系统管理程序。这些特权指令涉及内存管理、中断处理、异常处理、硬件控制和安全机制等关键功能。文档由Andrew Waterman和Krste Asanović共同编辑，他们分别来自SiFive公司和加州大学伯克利分校的电子工程与计算机科学系。此版本为2019年6月8日的最新修订，已经获得了批准，并列出了众多贡献者的名单，他们的工作共同塑造了这一标准。该文档的主要内容涵盖了以下几个核心主题： 1. **特权指令集**：特权指令集提供了访问系统资源的权限，如设置陷阱和异常处理，执行内存管理操作（如页表管理和内存保护），以及控制中断处理。 2. **系统管理功能**：包括对设备控制器的编程接口，以便操作系统可以配置和管理外设，如I/O端口、中断控制器、定时器等。 3. **内存管理单元** (MMU)：特权架构中通常包含一个MMU，用于虚拟内存管理和地址空间布局，这对于多任务和安全环境至关重要。 4. **异常和中断处理**：异常处理机制允许系统在遇到错误或请求时进行恢复，而中断管理则负责协调处理器响应外部事件的能力。 5. **安全性考虑**：特权架构中可能包含了安全特性和机制，以防止恶意代码滥用权限，如地址空间布局随机化（ASLR）和权限分离。 6. **标准和规范**：文档强调了RISC-V作为开放标准的性质，所有的规格和实现都遵循共同的规定，促进了生态系统内的互操作性和可移植性。 7. **贡献者合作**：这份文档的成功依赖于众多专家的协作，他们持续更新和改进标准，确保RISC-V架构能满足不断发展的技术需求。通过阅读RISC-V-privileged-20190608-1.pdf，系统设计者和开发者能够深入了解如何构建高效、安全的RISC-V系统，以及如何利用特权指令来实现操作系统级的复杂任务。这份文档是理解和开发基于RISC-V平台的关键参考资料。

资源详情

资源推荐

Volume II: RISC-V Privileged Architectures V20190608-Priv-MSU-Ratiﬁed 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.

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.

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.

Many RISC-V implementations will also support at least user mode (U-mode) to protect the rest

of the system from application code. Supervisor mode (S-mode) can be added to provide isolation

between a supervisor-level operating system and the SEE.

A hart normally runs application code in U-mode until some trap (e.g., a supervisor call or a timer

interrupt) forces a switch to a trap handler, which usually runs in a more privileged mode. The hart

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), and all other privileged instructions. 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

exceptions. A read/write register might also contain some bits that are read-only, in which case

writes to the read-only bits are ignored.

剩余90页未读，继续阅读

jnjn0022

粉丝: 0
资源: 1

RISC-V特权架构手册：2019年6月8日发布，操作系统与设备支持详解

riscv-privileged-spec-v1.7中文版

riscv-privileged-20211203.pdf

riscv-privileged-20190608.pdf

docker--privileged

怎么用--privileged=true 进入容器

-v ./seata:/seata-server/resources \ --privileged=true \ --network hm-net \ -d \ seataio/seata-server:1.5.2

怎么给容器开放-privileged=true

--privileged

sudo docker run --privileged=true -itd

docker run -itd --restart=always --privileged --cap-add SYS_PTRACE --name prod-env-xy

docker创建容器配置了--privileged -u root --entrypoint使用k8s使用镜像创建pod是不是也要配置超级用户

docker run -itd -p 80:80 --name=web1 --privileged nginx:latest分别解释

docker启动参数--privileged=true

普通用户可以特权方式启动docker容器吗？docker run --privileged

kube-apiserve配置文件r--allow-privileged=true

docker --privileged

docker --privileged=true

docker run -it --privileged --name ***** vtcpiso:v2.0.1 bash

docker-19.03.11-dind安装buildx

docker run -itd -p 9090:8080 -p 50000:50000 --name jenkins --privileged=true -v /home/jenkins:/var/jenkins_home jenkins/jenkins:lts

最新资源