No projeto atual, é responsabilidade da(s) MMU(s) fazer tudo menos o principal, que é justamente traduzir endereços lógicos/virtuais vindos da CPU para endereços físicos, que serão enviados para o Controlador de Memória/Barramento.
Existem várias decisões de design que precisam ser consideradas antes de começarmos esse trabalho, como por exemplo:
Quantos níveis de privilégio a CPU vai suportar?
Implementar só o modo M (Machine) dispensaria completamente a virtualização de memória (endereço lógico = endereço virtual), e toda requisição de dados da CPU para as MMUs que não estiverem na cache podem ser repassadas para o Controlador de Memória. É o que já está sendo feito!
Se entendi bem o manual, somente o modo S (Supervisor) realmente requer virtualização. Só os modos U (User) + M não precisa.
Como implementar o esquema de virtualização? Padrão dita que deve ser por paginamento (em oposição a segmentação). Ver Seção 4.3 do manual (Sv32: Page-Based 32-bit Virtual-Memory Systems).
Como implementar proteção de memória, gerar page-faults em caso de acessos ilegais ou misses da TLB, e como a CPU deve reagir a esses eventos?
No projeto atual, é responsabilidade da(s) MMU(s) fazer tudo menos o principal, que é justamente traduzir endereços lógicos/virtuais vindos da CPU para endereços físicos, que serão enviados para o Controlador de Memória/Barramento.
Existem várias decisões de design que precisam ser consideradas antes de começarmos esse trabalho, como por exemplo:
Machine) dispensaria completamente a virtualização de memória (endereço lógico = endereço virtual), e toda requisição de dados da CPU para as MMUs que não estiverem na cache podem ser repassadas para o Controlador de Memória. É o que já está sendo feito!Supervisor) realmente requer virtualização. Só os modos U (User) + M não precisa.Referências: RISC-V Privileged Specification: https://github.com/riscv/riscv-isa-manual/releases/tag/Priv-v1.12