riscv-pk icon indicating copy to clipboard operation
riscv-pk copied to clipboard

Redundant Load and Branch Instructions from HTIF while executing binaries

Open RRavikiran66 opened this issue 1 year ago • 3 comments

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.

RRavikiran66 avatar Jan 31 '24 17:01 RRavikiran66

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.

jerryz123 avatar Jan 31 '24 17:01 jerryz123

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?

RRavikiran66 avatar Jan 31 '24 19:01 RRavikiran66

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?

sawansib avatar Jan 31 '24 20:01 sawansib