QEMU hangs on Vx32

[davidharrishmc]

Set EXTENSIONS=Vx32 in Makefile
make vector-tests
make qemu

Runs through the tests and prints

══════ qemu-rv64-max ══════
  Running ELFs from: /home/harris/cvw/addins/riscv-arch-test-dh/work/qemu-rv64-max/elfs
  Using command: qemu-system-riscv64 -nographic -semihosting -icount shift=1 -machine virt -cpu max,pmu-mask=0xfffffff8 -bios <elf_path>
  Summary available at: /home/harris/cvw/addins/riscv-arch-test-dh/work/qemu-rv64-max/summary.log

but hangs after that point and never makes a summary.
The individual logs look ok.

[SurbhiAgarwal1]

Hi @davidharrishmc ,
I’ve been seeing this hang as well when testing the Vx32 extensions. It seems the framework’s process pool gets stuck waiting on a specific ELF that never returns from QEMU (possibly due to an enabled/disabled Vector state).

The simplest fix to prevent the entire framework from hanging would be to introduce a timeout in run_tests.py using subprocess.run(..., timeout=X).

This would:

1.Allow the rest of the tests to finish instead of blocking.
2.Report the hanging test as FAILED (TIMEOUT), making it much easier to isolate which ELF is causing the issue.
3.Would we want to add a default --timeout flag to the CLI, or should we just bake a standard 60-second limit into the execution loop? I’m happy to put together a PR for this if the approach sounds good!

[davidharrishmc]

There are some timeouts already in the framework. @jordancarlin can comment best on the status and on what development work would be most useful.

[jordancarlin]

run_tests.py already has a 5 minute timeout set, but there have been reports that the timeout isn't working correctly both in the build framework and in run_tests.py (see #1238). If you want to look into why the timeout isn't working and find a fix, that would be great.

[SurbhiAgarwal1]

Thanks for the clarification @jordancarlin — that helps a lot.

Got it, so the issue isn’t the absence of a timeout but that the existing timeout mechanism isn’t reliably terminating hanging QEMU processes.

I’ll dig into this from two angles:

1. Verify how the timeout is currently implemented in run_tests.py

   • whether it uses subprocess.run(..., timeout=...) or a custom wrapper
   • whether the timeout is being swallowed or not propagated correctly

2. Check process behavior under QEMU hangs

   • whether child processes (QEMU) are being properly terminated on timeout
   • if there are cases where the parent Python process exits the wait but QEMU keeps running (common with process groups)

If needed, I’ll propose a fix that:

• enforces timeout at the subprocess level reliably
• ensures QEMU is fully killed (including child processes)
• surfaces TIMEOUT status cleanly in the summary instead of hanging the framework

I’ll post findings + a minimal fix proposal shortly before opening a PR.