Re: [Qemu-devel] [PATCH v6 3/6] tests: in IDE and AHCI tests perform DMA write before flushing

[Evgeny Yakovlev <eyakovlev@virtuozzo.com>]

On 14.07.2016 19:05, Eric Blake wrote:
> On 07/14/2016 06:29 AM, Denis V. Lunev wrote:
>> From: Evgeny Yakovlev <eyakovlev@virtuozzo.com>
>>
>> Due to changes in flush behaviour clean disks stopped generating
>> flush_to_disk events and IDE and AHCI tests that test flush commands
>> started to fail.
>>
>> This change adds additional DMA writes to affected tests before sending
>> flush commands so that bdrv_flush actually generates flush_to_disk event.
>>
>> Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com>
>> Signed-off-by: Denis V. Lunev <den@openvz.org>
>> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
>> CC: Kevin Wolf <kwolf@redhat.com>
>> CC: Max Reitz <mreitz@redhat.com>
>> CC: Stefan Hajnoczi <stefanha@redhat.com>
>> CC: Fam Zheng <famz@redhat.com>
>> CC: John Snow <jsnow@redhat.com>
>> ---
>>   tests/ahci-test.c | 34 ++++++++++++++++++++++++++++++++--
>>   tests/ide-test.c  | 43 +++++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 75 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/ahci-test.c b/tests/ahci-test.c
>> index 57dc44c..d707714 100644
>> --- a/tests/ahci-test.c
>> +++ b/tests/ahci-test.c
>> @@ -1063,11 +1063,34 @@ static void test_dma_fragmented(void)
>>       g_free(tx);
>>   }
>>   
>> +/*
>> + * Write sector 0 with random data to make AHCI storage dirty
> If we ever have a case where we open a disk without specifying -raw, the
> random data _might_ resemble some other format and cause probe to
> misbehave; as such, we also have code in the block layer that
> specifically prevents writes to sector 0 for some data. Should you pick
> a different sector than 0, so as to avoid any (remote) possibility that
> the random data could change probe results or be rejected?
>

Not sure if i understand the problem you're referring to here. Those are 
blkdebug tests, those disks are created, emulated with blkdebug backend, 
flushed and then thrown away. So is there really any possibility for 
reopening the image and accidentally parsing a partition table in sector 0?

Also, not sure what you mean by "code in the block layer that
specifically prevents writes to sector 0 for some data". Can you explain 
that bit, because it sounds pretty scary. How can we deny guest VM to 
write anything to sector 0 on its emulated disk?