From 358625631012e0f30393e3069e4b6bac715d920f Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli <aarcange@redhat.com>
Date: Tue, 3 May 2011 19:09:49 -0300
Subject: [PATCH] ide: turn off ide warnings

RH-Author: Andrea Arcangeli <aarcange@redhat.com>
Message-id: <20110503190949.GU16653@random.random>
Patchwork-id: 23475
O-Subject: [PATCH qemu 5.7] ide: turn off ide warnings
Bugzilla: 508949
RH-Acked-by: Jes Sorensen <Jes.Sorensen@redhat.com>
RH-Acked-by: Markus Armbruster <armbru@redhat.com>
RH-Acked-by: Kevin Wolf <kwolf@redhat.com>

Hello,

This should fix bug 508949. When the iscsi server is down it should be
normal that warning happens here and aio retries and flood the
console.

https://bugzilla.redhat.com/show_bug.cgi?id=508949

Patch has zero risk of regressions.

The only risk is to hide a bug where errors will be ignored and the
guest OS will end up with a corrupted image, but it wouldn't be a
regression, just the flood on stdio will be gone when that
happens. With real local storage it's impossible to get a I/O failure,
the host storage drivers would keep retrying and if they fail it means
the hardware is dead (or partly dead), it's a definitive failure that
can't be gracefully recovered in software. So the printf was fine for
those. With networked storage a failure could be because of network
timeouts or network server rebooting.

I reviewed the error delivery and it's passed up to ide which
simulates a I/O error for the guest, so then it should be up to the
guest OS to retry long enough and deal with it without corrupting the
guest image. Often local filesystems in the guest (ext4/brfs/xfs
etc...) won't be heavily tested for I/O errors. So it would be
somewhat safer to retry on the qemu side without passing errors up to
the guest, OTOH the guest might eventually notice a DMA timeout if the
I/O doesn't complete in a timely fashion, so retrying indefinitely in
qemu aio layer wouldn't be a definitive solution to avoid triggering
guest os bugs... So in the end this is probably the simplest way we
can handle the iscsi server disconnect. Maybe we can do it better for
virtio as we have full control the guest driver (we don't control the
guest ide driver instead), but it's probably not worth working on this
for 5.x.

Andrea

PS. this isn't well tested as my new test system is failing to boot
with rhel5/master because of too new/many cpus :(, but as said the patch
is zero risk anyway.

====
Subject: ide: turn off ide warnings

From: Andrea Arcangeli <aarcange@redhat.com>

When iscsi server is disconnected I/O will not complete despite qemu_aio_flush
is called. This avoids a flood to stdio.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 qemu/hw/ide.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/qemu/hw/ide.c b/qemu/hw/ide.c
index 1b79362..448607f 100644
--- a/qemu/hw/ide.c
+++ b/qemu/hw/ide.c
@@ -3200,10 +3200,13 @@ static void bmdma_cmd_writeb(void *opaque, uint32_t addr, uint32_t val)
 	 */
 	if (bm->aiocb) {
 		qemu_aio_flush();
+#ifdef DEBUG_IDE
+
 		if (bm->aiocb)
-			printf("ide_dma_cancel: aiocb still pending");
+			printf("ide_dma_cancel: aiocb still pending\n");
 		if (bm->status & BM_STATUS_DMAING)
-			printf("ide_dma_cancel: BM_STATUS_DMAING still pending");
+			printf("ide_dma_cancel: BM_STATUS_DMAING still pending\n");
+#endif
 	}
         bm->cmd = val & 0x09;
     } else {
-- 
1.7.3.2