qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH v6 3/6] tests: in IDE and AHCI test


From: Evgeny Yakovlev
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v6 3/6] tests: in IDE and AHCI tests perform DMA write before flushing
Date: Fri, 15 Jul 2016 11:08:19 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0



On 14.07.2016 19:05, Eric Blake wrote:
On 07/14/2016 06:29 AM, Denis V. Lunev wrote:
From: Evgeny Yakovlev <address@hidden>

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 <address@hidden>
Signed-off-by: Denis V. Lunev <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
CC: Kevin Wolf <address@hidden>
CC: Max Reitz <address@hidden>
CC: Stefan Hajnoczi <address@hidden>
CC: Fam Zheng <address@hidden>
CC: John Snow <address@hidden>
---
  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?






reply via email to

[Prev in Thread] Current Thread [Next in Thread]