Re: [Qemu-devel] [PATCH 1/3] qtest: add register fuzzing to RTC test

[Blue Swirl]

On Mon, Apr 16, 2012 at 00:49, Andreas Färber <address@hidden> wrote:
> Am 15.04.2012 18:32, schrieb Blue Swirl:
>> Signed-off-by: Blue Swirl <address@hidden>
>> ---
>>  tests/rtc-test.c |   17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/tests/rtc-test.c b/tests/rtc-test.c
>> index 983a980..f23ac3a 100644
>> --- a/tests/rtc-test.c
>> +++ b/tests/rtc-test.c
>> @@ -240,6 +240,22 @@ static void alarm_time(void)
>>      g_assert(cmos_read(RTC_REG_C) == 0);
>>  }
>>
>> +/* success if no crash or abort */
>> +static void fuzz_registers(void)
>> +{
>> +    unsigned int i;
>> +
>> +    for (i = 0; i < 1000; i++) {
>> +        uint8_t reg, val;
>> +
>> +        reg = (uint8_t)g_test_rand_int_range(0, 16);
>> +        val = (uint8_t)g_test_rand_int_range(0, 256);
>> +
>> +        cmos_write(reg, val);
>> +        cmos_read(reg);
>> +    }
>> +}
>
> I wonder if this is really what we want... Don't we rather want to test
> all 16 registers with random values? Are we not doing two nested loops
> due to register interdependencies, i.e. for random access order?

The possibilities are endless. One quick test would be to just write 0
 to all registers in sequence and then the same with 0xff. We could
test register multiplexing by trying also (non-existent) registers
above 15. Another view to multiplexing is that outl should produce
same effect as two outws and four outbs, maybe not for all hardware.
Going slightly higher in smartness, we could fill alarm registers with
random data and then enable alarm to see how the chip emulation copes
with bad dates.

The goal is to find bugs, adding more tests or more complex tests may
find more bugs but I guess that with random testing the returns will
be diminishing.

>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg