OpenXiangShan
[Bug Report] `mie` register not implemented correctly
According to the privileged specification in chapter 3.1.9. Machine Interrupt Registers, some bits in MIE are set to zero.
However, if we write 0xffffffff to mie, the NEMU will set it to 0xffffffff.
The bug was found when I tested Xiangshan. This is the test program mie_bug.zip.
Here are some env information:
NEMU commit: 3033a69f, xs-env commit: master, Xiangshan commit: 8fae59bba.
Hi @huxuan0307,
I have tested this bug in the newest version NEMU, commit id is 821ea961. I changed some code in order to run ./build/riscv64-nemu-interpreter -d ./ready-to-run/riscv64-spike-so -b mie.bin.
Actually, I doubt the reference spike is not correct because I ran the code in spike, the 1.1.1-dev version, the right value is mie = 0x0000000000000aaa after we write it.
Is there a way to run NEMU like spike step by step? I have not found it. I want to help to improve NEMU.
In src/isa/riscv64/system/priv.c, you can look at the source code for writing the mie register. We now support the RV_H and RV_SSCOFPMF extensions, so the corresponding bits of mie are readable and writable.
We made a modification based on Spike, you can get it in https://github.com/OpenXiangShan/riscv-isa-sim. If you want to modify and generate spike-so that diff with NEMU, you can read README in riscv-isa-sim/difftest/
Besides, You can remove the -b option and run ./build/riscv64-nemu-interpreter -d ./ready-to-run/riscv64-spike-so mie.bin. Execute help to view options.
Thanks for your reply @sinceforYy.
I have RTFM in chapter 17 & 18.4, NEMU 821ea961 version is right, but 3033a69 was wrong, as we can see the picture in my first comment:
Yes, xiangshan supports the RV_H and RV_SSCOFPMF extensions, so NEMU
821ea961 version is right when we write 0xffffffff to mie:
C17: Note that the new count overflow interrupt will be treated as a standard local interrupt that is assigned to bit 13 in the mip/mie/sip/sie registers.
This bug had been fixed.