Hi Alex, October 14, 2025 at 2:47 PM, "Alex Bennée" wrote: > Julian Ganz <[email protected]> writes: > > > > > This test aims at catching API misbehaviour w.r.t. the interaction > > between interrupts and memory accesses, such as the bug fixed in > > > > 27f347e6a1d269c533633c812321cabb249eada8 > > > Even better the abbrev with title: > > 27f347e6a1d (accel/tcg: also suppress asynchronous IRQs for cpu_io_recompile)
Will do. > > Because the condition for triggering misbehaviour may not be > > deterministic and the cross-section between memory accesses and > > interrupt handlers may be small, we have to place our trust in large > > numbers. Instead of guessing/trying an arbitrary, fixed loop-bound, we > > decided to loop for a fixed amount of real-time. This avoids the test > > running into a time-out on slower machines while enabling a high number > > of possible interactions on faster machines. > > > > Reviewed-by: Daniel Henrique Barboza <[email protected]> > > Signed-off-by: Julian Ganz <[email protected]> > > --- > > tests/tcg/riscv64/Makefile.softmmu-target | 6 ++ > > tests/tcg/riscv64/interruptedmemory.S | 67 +++++++++++++++++++++++ > > 2 files changed, 73 insertions(+) > > create mode 100644 tests/tcg/riscv64/interruptedmemory.S > > > > diff --git a/tests/tcg/riscv64/Makefile.softmmu-target > > b/tests/tcg/riscv64/Makefile.softmmu-target > > index 1a71a78653..d8f92b8e61 100644 > > --- a/tests/tcg/riscv64/Makefile.softmmu-target > > +++ b/tests/tcg/riscv64/Makefile.softmmu-target > > @@ -30,5 +30,11 @@ run-plugin-doubletrap: doubletrap > > $(QEMU) -plugin ../plugins/libdiscons.so -d plugin -D $*.pout \ > > $(QEMU_OPTS)$<) > > > > +EXTRA_RUNS += run-plugin-interruptedmemory > > +run-plugin-interruptedmemory: interruptedmemory > > + $(call run-test, $<, \ > > + $(QEMU) -plugin ../plugins/libdiscons.so -d plugin -D $*.pout \ > > + $(QEMU_OPTS)$<) > > > Something went wrong with substitutions there because I see: > > timeout -s KILL --foreground 120 > /home/alex/lsrc/qemu.git/builds/all/qemu-system-riscv64 -plugin > ../plugins/libdiscons.so -d plugin -D .pout -M virt -display none > -semihosting -device loader,file=interruptedmemory I fail to see the issue right now. I'll have to dig a bit and compare this to other tests. > There doesn't seem to be any output either when I run it manually - > should we be checking the output and at least confirming we are > detecting the right sort of events? The test currently only communicates success and failure via the return value (via semihosting). I can add additional output. Printing at least the final result is probably a good idea. > > + > > # We don't currently support the multiarch system tests > > undefine MULTIARCH_TESTS > > diff --git a/tests/tcg/riscv64/interruptedmemory.S > > b/tests/tcg/riscv64/interruptedmemory.S > > new file mode 100644 > > index 0000000000..a32d672849 > > --- /dev/null > > +++ b/tests/tcg/riscv64/interruptedmemory.S > > @@ -0,0 +1,67 @@ > > + .option norvc > > + > > + .text > > + .global _start > > +_start: > > + # Set up trap vector > > + lla t0, trap > > + csrw mtvec, t0 > > + > > + # Set up timer > > + lui t1, 0x02004 > > + sd zero, 0(t1) # MTIMECMP0 > > + > > + # Enable timer interrupts > > + li t0, 0x80 > > + csrrs zero, mie, t0 > > + csrrsi zero, mstatus, 0x8 > > + > > + # Find out when to stop > > + call rtc_get > > + li t0, 60 > > + slli t0, t0, 30 # Approx. 10e9 ns > > + add t0, t0, a0 > > > The runtime of 60s seems quite long for a tcg test. Can we not show > stuff happening in a shorter period of time? I can simply reduce the time, e.g. to 30s. I can also add some output every X iteratins or every second (with the number of iterations) so we get an idea how many chances we had to trigger the regression. Regards, Julian
