Обозначение адреса в RIS C -V

Question

Я использую моделируемое ядро ​​RV64G C в QEMU и пытаюсь лучше понять подсистему виртуальной памяти и процесс преобразования адресов в RIS C -V. Моя моделируемая система работает с OpenSBI, Linux Kernal v5.5 и минимальным rootfs.

В трассировках отладки QEMU я вижу, что иногда (чаще всего с ecalls) управление передается в SBI и адреса меняются с адресов ядра (виртуальных?) со смещением 0xffffffe000000000 на нечто, похожее на реальные физические адреса в ОЗУ. Например,

...

0xffffffe00003a192: 00000073 ecall

...

IN: sbi_ecall_0_1_handler

0x0000000080004844 : 00093603 ld a2,0 (s2)

0x0000000080004848: 4785 addi a5, ноль, 1

0x000000008000484a: 00a797b3 sll a5, a5, a0

...

В версии 1.11 привилегированной спецификации RIS C -V, раздел 4.1.12, в CSP satp (регистр управления и состояния) определено поле MODE, которое определяет обозначение преобразования адреса. РЕЖИМ 0 означает, что трансляция пуста (адреса считаются физическими), РЕЖИМ 8 или 9 требует виртуальной адресации на основе страниц Sv39 или Sv48, соответственно, и любые другие значения РЕЖИМА зарезервированы.

Теперь, как привилегированные, так и непривилегированные спецификации RIS C -V, по-видимому, не упоминают, когда можно изменить satp (кроме как с помощью csrrw), поэтому это приводит меня к следующим вопросам:

Когда управление передается SBI (как с ecall выше), изменится ли режим satp на 0? Если да, означает ли это, что режим satp должен быть сброшен по команде au / s / mret? Существуют ли другие случаи (кроме csrrw), где предполагается изменить satp?

Если нет, существует ли какой-либо другой механизм, с помощью которого адреса интерпретируются и обозначаются как физические? Или адреса (адреса 0x80XXXXXX выше) вместо этого считаются виртуальными и должны go проходить через обычный процесс преобразования виртуальных адресов (как описано в разделе 4.3.2 привилегированной спецификации RIS C -V)? Если это так, когда для этого создаются записи в таблице страниц?

Answer 1

Модель памяти RIS C -V работает следующим образом:

M режим имеет свою собственную систему защиты памяти, описанную в разделе 3.6 привилегированных спецификаций, называемых PMP (защита физической памяти). Это делается для защиты памяти на более низких уровнях привилегий, а также для самого режима M (если используется бит блокировки). В режиме М нет системы виртуальной памяти.

Теперь в режиме S он имеет систему виртуальной памяти на основе страниц, которую режим S может использовать для установки виртуального преобразования в физический адрес, а также для наложения ограничений памяти на сам режим S, а также на режим U.

Таким образом, каждый уровень привилегий имеет контроль над своими собственными ресурсами и ресурсами под ним, но никогда над ресурсами уровня привилегий над ним. Вот как все работает.

Режим M может управлять памятью, доступной в режимах M, S и U, а режим S может контролировать вид памяти (виртуальную память) и доступность режимов S и U, а не режима M. Таким образом, режим перехода в режим ожидания никогда не меняется даже при переходе в режим М. Как указывает на это отображение, оно никогда не применимо к М-режиму. Он имеет встроенный модуль защиты памяти.

Это было бы огромной дырой в безопасности, если более низкие уровни привилегий могут накладывать ограничения памяти на более высокие уровни привилегий.