Open yf13 opened 9 months ago
@yf13 thank you for reading the post and reporting the issue! This did change in newer versions of QEMU -- are you running QEMU with all the flags specified?
qemu-system-riscv64 -machine virt -cpu rv64,pmp=false -smp 1 -s -S -nographic -bios none -kernel entry
Specifically, the pmp=false
is required in this case. This is mentioned in an update in the post:
Update (5/26/23): Physical Memory Protection (PMP) is now enabled by default in qemu-system-riscv64 (ref). We disable with the pmp=false flag to avoid our first mret instruction causing an exception and trapping to m_trap rather than returning to supervisor. Thanks to Kevin Xue for reporting this!
Is it still not working correctly for you with pmp=false
set?
@hasheddan No, the first mret
still doesn't enter supervisor
here.
$ ps -ef | fgrep 6011
yf 6011 1 0 09:57 pts/1 00:00:00 qemu-system-riscv64 -M virt -cpu rv64,pmp=false -smp 1 -nographic -bios none -kernel build/entry -s -S
BTW, why having PMP will cause first mret
being illegal instruction?
Thanks for sharing the blog: https://danielmangum.com/posts/risc-v-bytes-privilege-levels/
However, on Ubuntu Jammy (22.04) with stock
qemu-system-riscv64
, theentry.s
, the firstmret
leads tom_trap
instead ofsupervisor
.It seems that the
mret
instruction at end of_start
part is illegal instruction now. Is there something changed?