As we are converting most fuzzers to rely on reboots to reset state,
introduce an API to make sure reboots are invoked in a consistent
manner.

Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
---
 tests/qtest/fuzz/fuzz.c | 6 ++++++
 tests/qtest/fuzz/fuzz.h | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/tests/qtest/fuzz/fuzz.c b/tests/qtest/fuzz/fuzz.c
index eb7520544b..c2d07a4c7e 100644
--- a/tests/qtest/fuzz/fuzz.c
+++ b/tests/qtest/fuzz/fuzz.c
@@ -51,6 +51,12 @@ void flush_events(QTestState *s)
     }
 }
 
+void fuzz_reboot(QTestState *s)
+{
+    qemu_system_reset(SHUTDOWN_CAUSE_GUEST_RESET);
+    main_loop_wait(true);
+}
+
 static QTestState *qtest_setup(void)
 {
     qtest_server_set_send_handler(&qtest_client_inproc_recv, &fuzz_qts);
diff --git a/tests/qtest/fuzz/fuzz.h b/tests/qtest/fuzz/fuzz.h
index 327c1c5a55..69e2b3877f 100644
--- a/tests/qtest/fuzz/fuzz.h
+++ b/tests/qtest/fuzz/fuzz.h
@@ -103,7 +103,7 @@ typedef struct FuzzTarget {
 } FuzzTarget;
 
 void flush_events(QTestState *);
-void reboot(QTestState *);
+void fuzz_reboot(QTestState *);
 
 /* Use the QTest ASCII protocol or call address_space API directly?*/
 void fuzz_qtest_set_serialize(bool option);
-- 
2.39.0

On 5/2/23 05:29, Alexander Bulekov wrote:
> As we are converting most fuzzers to rely on reboots to reset state,
> introduce an API to make sure reboots are invoked in a consistent
> manner.
> 
> Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
> ---
>   tests/qtest/fuzz/fuzz.c | 6 ++++++
>   tests/qtest/fuzz/fuzz.h | 2 +-
>   2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/qtest/fuzz/fuzz.c b/tests/qtest/fuzz/fuzz.c
> index eb7520544b..c2d07a4c7e 100644
> --- a/tests/qtest/fuzz/fuzz.c
> +++ b/tests/qtest/fuzz/fuzz.c
> @@ -51,6 +51,12 @@ void flush_events(QTestState *s)
>       }
>   }
>   
> +void fuzz_reboot(QTestState *s)

"reboot" sounds like guest software triggered.
IIUC from the fuzzer PoV this is more a "power-cycle" right?

> +{
> +    qemu_system_reset(SHUTDOWN_CAUSE_GUEST_RESET);

Is SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET more appropriate?

> +    main_loop_wait(true);
> +}

On Sunday, 2023-02-05 at 11:50:52 +01, Philippe Mathieu-Daudé wrote:
> On 5/2/23 05:29, Alexander Bulekov wrote:
>> As we are converting most fuzzers to rely on reboots to reset state,
>> introduce an API to make sure reboots are invoked in a consistent
>> manner.
>> 
>> Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
>> ---
>>   tests/qtest/fuzz/fuzz.c | 6 ++++++
>>   tests/qtest/fuzz/fuzz.h | 2 +-
>>   2 files changed, 7 insertions(+), 1 deletion(-)
>> 
>> diff --git a/tests/qtest/fuzz/fuzz.c b/tests/qtest/fuzz/fuzz.c
>> index eb7520544b..c2d07a4c7e 100644
>> --- a/tests/qtest/fuzz/fuzz.c
>> +++ b/tests/qtest/fuzz/fuzz.c
>> @@ -51,6 +51,12 @@ void flush_events(QTestState *s)
>>       }
>>   }
>>   
>> +void fuzz_reboot(QTestState *s)
>
> "reboot" sounds like guest software triggered.
> IIUC from the fuzzer PoV this is more a "power-cycle" right?

I think that 'fuzz_reset()' or 'fuzz_reset_state()' would make sense,
the primary purpose is to reset the fuzzing back to a known state, as
said in the commit message.

While right now it is a reboot, it may not always be, or could require
something more.

Thanks,

Darren.