> On 28 May 2020, at 11:26, Philippe Mathieu-Daudé <f4...@amsat.org> wrote:
>
> Hi,
>
> Some devices use timers (QEMUTimer) to emulate hardware precise timings.
> i.e. with a flash device, the guest orders erasing it, the physical
> erasure takes some time - let say 200ms - and upon completion a bit is
> set in a register, and an interruption is eventually raised.
> When not multi-tasking, a guest usually poll the register until bit set.
>
> While fuzzing, a payload schedule triggers an erase, then (if we don't
> reset the device) thousands of payloads are tested in vain until the
> device is ready to process further requests. It is then hard to
> understand the patterns used (in 200ms libFuzzer tried ~5000 I/O
> other accesses). Even if we can reproduce the pattern with proper
> timings, it is also hard to reproduce.
>
> Since we run the fuzzer with the QTest accelerator, my first idea was to
> check for 'if (qtest_enabled())' in the timer code, and directly expire
> a timer instead of scheduling it. This way we can test reproducers.
> However various tests require/verify precise timing, so this would break
> various qtests.
>
> Second idea was to add a fuzzer_enabled() method, and check it. But then
> I noticed some devices use timers the other way, they start a timer and
> wait an event to happen in a correct amount of time, else the timer kick
> and error bit is set (this is the watchdog style). If I modify the
> timers to directly expire checking fuzzer_enabled(), then these devices
> enter failure mode directly without processing further requests.
>
> So I guess I have to go thru each device and check for fuzzer_enabled()
> where appropriate...
> Any clever ideas?
Would it make sense to introduce the idea of device reservation / exclusivity
in the tests? In other words, if you have an “erase”, then you add some
“qtest_reserve_device(device, timeout, …)” and then modify the payload
scheduling to avoid reserved devices.
If there are less of these cases than general watchdogs, this may be a
win in the end, and also clarify the intent.
>
> Thanks
>
> Phil.
>
