Penunjukan alamat di RISC-V

Saya menjalankan inti simulasi RV64GC di QEMU dan mencoba untuk lebih memahami subsistem memori virtual dan proses penerjemahan alamat di RISC-V. Sistem simulasi saya berjalan dengan OpenSBI, Linux Kernal v5.5, dan rootfs minimal.

Dalam jejak debug QEMU, saya melihat bahwa kadang-kadang (paling sering dengan ecalls) kontrol diteruskan ke SBI dan alamatnya berubah dari alamat kernel (virtual?) dengan offset 0xffffffe000000000 menjadi sesuatu yang terlihat seperti alamat fisik nyata di RAM. Misalnya,

...

0xffffffe00003a192: 00000073 panggilan telepon

...

DI: sbi_ecall_0_1_handler

0x0000000080004844: 00093603 ld a2,0(s2)

0x0000000080004848: 4785 tambahan a5,nol,1

0x000000008000484a: 00a797b3 masih a5,a5,a0

...

Dalam spesifikasi istimewa RISC-V versi 1.11, bagian 4.1.12, satp CSR (kontrol dan register negara) didefinisikan memiliki bidang MODE yang menentukan penunjukan terjemahan alamat. MODE 0 berarti terjemahan kosong (alamat dianggap fisik), MODE 8 atau 9 masing-masing memerlukan pengalamatan virtual berbasis halaman Sv39 atau Sv48, dan nilai MODE lainnya dicadangkan.

Sekarang, spesifikasi istimewa dan tidak istimewa RISC-V sepertinya tidak menyebutkan kapan satp dapat diubah (selain dengan csrrw), jadi ini membawa saya ke pertanyaan berikut:

Ketika kendali diserahkan kepada SBI (seperti ecall di atas), apakah satp MODE berubah menjadi 0? Jika ya, apakah ini berarti mode satp harus direset pada instruksi u/s/mret? Apakah ada kejadian lain (selain csrrw) di mana satp seharusnya berubah?

Jika tidak, apakah ada mekanisme lain yang digunakan untuk menafsirkan dan menetapkan alamat sebagai alamat fisik? Atau apakah alamatnya (alamat 0x80XXXXXX di atas) dianggap virtual dan harus melalui proses penerjemahan alamat virtual biasa (sebagaimana diuraikan dalam bagian 4.3.2 dari spesifikasi istimewa RISC-V)? Jika demikian, kapan entri tabel halaman dibuat untuk ini?


person Josh    schedule 01.04.2020    source sumber


Jawaban (1)


Model memori RISC-V bekerja dengan cara berikut:

Mode M memiliki sistem perlindungan memorinya sendiri yang dijelaskan pada bagian 3.6 dari spesifikasi istimewa yang disebut PMP (perlindungan memori fisik). Hal ini untuk menerapkan perlindungan memori pada tingkat hak istimewa yang lebih rendah dan juga mode M itu sendiri (jika bit kunci digunakan). Tidak ada sistem memori virtual dalam mode M.

Sekarang dalam mode S, ia memiliki sistem memori virtual berbasis halaman yang dapat digunakan mode S untuk mengatur pemetaan alamat virtual ke fisik dan juga untuk menerapkan pembatasan memori pada mode S itu sendiri dan juga mode U.

Jadi setiap tingkat hak istimewa memiliki kendali atas sumber dayanya sendiri dan sumber daya di bawahnya, tetapi tidak pernah atas sumber daya pada tingkat hak istimewa di atasnya. Beginilah cara kerjanya.

Mode M dapat mengontrol memori yang dapat diakses oleh mode M, S dan U, dan mode S dapat mengontrol tampilan memori (memori virtual) dan aksesibilitas mode S dan U tetapi tidak pada mode M. Jadi mode satp pun tidak pernah berubah ketika berpindah ke mode M. Seperti yang ditunjukkan oleh pemetaan, itu bahkan tidak pernah berlaku untuk mode M. Ia memiliki unit perlindungan memori.

Ini akan menjadi lubang keamanan yang sangat besar jika tingkat hak istimewa yang lebih rendah dapat memaksakan pembatasan memori pada tingkat hak istimewa yang lebih tinggi.

person R.k. Lohana    schedule 08.04.2020