riscv-software-src / riscv-pk

RISC-V Proxy Kernel
Other
570 stars 304 forks source link

Redundant Load and Branch Instructions from HTIF while executing binaries #314

Open RRavikiran66 opened 5 months ago

RRavikiran66 commented 5 months ago

When executing the MIbench/telecomm/crc benchmark or any other benchmark in Mibench on the RISC-V ISA simulator (Spike), the execution log shows a repetitive pattern of two identical instructions, specifically load and branch instructions. It is observed that these instructions are originating from HTIF (Host-Target Interface) and not from the ELF file being executed. I have tried to trace it down I found that this pattern begins from mret and continues till sret. So, the Spike enters the machine mode to supervisor mode because of a trap but how can we avoid this? Or it's just the part of Spike.

Questions: Expected Behavior: Is the repetition of identical load and branch instructions from HTIF expected behavior in the Spike simulator when running the MIbench benchmark?

Mitigation: How can these redundant load and branch instructions from HTIF be avoided in order to improve the accuracy and efficiency of the simulation? Are there specific configurations or settings that need to be adjusted?

Environment: Host Operating System: Fedora workstation 37 Target Architecture: RISC-V Benchmark: MIbench/telecomm/crc

Additional Information: I have generated the log, below is a small part of the log(I get the same pattern for millions of iterations):

core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4 core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0) core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4`

Thank you for your assistance in addressing this issue.

jerryz123 commented 5 months ago

PK uses the HTIF interface for syscalls. The HTIF interface is through polling reads and writes to special memory addresses (tohost/fromhost). You are likely seeing polling on fromhost due to some syscalls from your target benchmark.

If you are evaluating some benchmark using PK, you must be careful that there are no syscalls in the region of interest in the benchmark.

RRavikiran66 commented 5 months ago

Thanks a lot for your reply, For that, I have marked the whole PK as a junkROI and If I'm inside the PK(i.e- Junk Region in my case) I don't update the stats or trace. Even with this, I see a lot of Instructions that are not from the binary that I'm executing. Is there a way to get PC(IP) in the trace that is only in the binary that I'm executing?

sawansib commented 5 months ago

Hello @jerryz123 ,

I've observed a comparable trace as well. I suspect this occurs for any trap involving syscalls. The behavior is consistent even when running a complete Linux environment on Spike. Given that the Linux setup is expected to support all syscalls, could this behavior occur due to other traps, like misaligned memory access?