Re: [PATCH v1] tests/qtest: Avoid timers from default devices

[Fabiano Rosas <farosas@suse.de>]

Stefan Hajnoczi <stefanha@gmail.com> writes:

> On Tue, Apr 28, 2026 at 12:04 PM Fabiano Rosas <farosas@suse.de> wrote:
>>
>> Having default devices enabled while testing timers leads to
>> non-deterministic behavior on the usage of the QTest
>> qtest_clock_step_next() command as the implicit devices can have
>> timers of their own that may have a deadline more recent than the
>> tested device.
>>
>> In the particular case of npcm7xx-timer-test, having SLIRP enabled in
>> the QEMU binary may cause the net_slirp_timer to shadow the clock
>> advance that was expected to trigger the NPCM7xx timer:
>>
>> npcm7xx_timer-test.c:475:test_periodic_interrupt:
>>   assertion failed (tim_read(td, TISR) == tim_timer_bit(td)): (0x00000000 == 0x00000010)
>> npcm7xx_timer-test.c:476:test_periodic_interrupt:
>> 'qtest_get_irq(global_qtest, tim_timer_irq(td))' should be TRUE
>>
>> Add the -nodefaults command line option to all tests that invoke
>> qtest_clock_step_next.
>>
>> CC: Alex Bennée <alex.bennee@linaro.org>
>> Reported-by: Stefan Hajnoczi <stefanha@redhat.com>
>> Signed-off-by: Fabiano Rosas <farosas@suse.de>
>> ---
>>  tests/qtest/npcm7xx_timer-test.c | 2 +-
>>  tests/qtest/pflash-cfi02-test.c  | 4 ++--
>>  tests/qtest/rtc-test.c           | 2 +-
>>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> Hi Fabiano,
> Thank you for the patch! I'm not sure this is a long-term fix since
> any code in QEMU could use timers (monitor, io channels, etc)?
>

Good point, if we go this way I'll add more words to the commit message
to make that pitfall clear.

@Alex, I was even under the impression that the issues with slirp timers
getting in the way of clock_step were entirely fixed by your changes
from:
https://lore.kernel.org/r/20250210161451.3273284-1-alex.bennee@linaro.org

Was that the intention at the time? Should we consider a timer test that
expects it to fire right after advancing the clock a mistake in the
test?

> Whether it is a full fix or not, it's definitely an improvement:
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>