Я запускаю смоделированное ядро RV64GC в QEMU и пытаюсь лучше понять подсистему виртуальной памяти и процесс преобразования адресов в RISC-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 доп. A5, ноль, 1
0x000000008000484a: 00a797b3 sll a5, a5, a0
...
В привилегированной спецификации RISC-V версии 1.11, раздел 4.1.12, satp CSR (регистр управления и состояния) определен как имеющий поле MODE, которое определяет обозначение трансляции адресов. РЕЖИМ 0 означает, что преобразование является пустым (адреса считаются физическими), РЕЖИМ 8 или 9 требует виртуальной адресации на основе страниц Sv39 или Sv48 соответственно, а любые другие значения РЕЖИМА зарезервированы.
Теперь, как привилегированные, так и непривилегированные спецификации RISC-V, похоже, не упоминают, когда можно изменить satp (кроме csrrw), поэтому это приводит меня к следующим вопросам:
Когда управление передается SBI (как в случае вышеупомянутого вызова), изменится ли РЕЖИМ satp на 0? Если да, значит ли это, что режим satp должен быть сброшен по инструкции u / s / mret? Существуют ли другие случаи (кроме csrrw), где предполагается изменение satp?
Если нет, существует ли другой механизм, с помощью которого адреса интерпретируются и обозначаются как физические? Или адреса (адреса 0x80XXXXXX выше) вместо этого считаются виртуальными и должны пройти обычный процесс преобразования виртуальных адресов (как описано в разделе 4.3.2 привилегированной спецификации RISC-V)? Если это так, когда для этого создаются записи в таблице страниц?
