[Qemu-devel] [PATCH] ide_dma_cancel will result in partial DMA transfer (resend #3)

[Qemu-devel] [PATCH] ide_dma_cancel will result in partial DMA transfer (resend #3)

[Andrea Arcangeli]

From: Andrea Arcangeli <aarcange@redhat.com>

The reason for not actually canceling the I/O is because with
virtualization and lots of VM running, a guest fs may mistake a
overload of the host, as an IDE timeout. So rather than canceling the
I/O, it's safer to wait I/O completion and simulate that the I/O has
completed just before the io cancellation was requested by the
guest. This way if ntfs or an app writes data without checking for
-EIO retval, and it thinks the write has succeeded, it's less likely
to run into troubles. Similar issues for reads.

Furthermore because the DMA operation is splitted into many synchronous
aio_read/write if there's more than one entry in the SG table, without this
patch the DMA would be cancelled in the middle, something we've no idea if it
happens on real hardware too or not. Overall this seems a great risk for zero
gain.

This approach is sure safer than previous code given we can't pretend all guest
fs code out there to check for errors and reply the DMA if it was completed
partially, given a timeout would never materialize on a real harddisk unless
there are defective blocks (and defective blocks are practically only an issue
for reads never for writes in any recent hardware as writing to blocks is the
way to fix them) or the harddisk breaks as a whole.

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

This is a resubmit of an old patch in my queue. Wonder if it'll ever
be merged. I think it's obviously safer (especially once we've
preadv/pwritev driven I/O) even if a noop.

Index: hw/ide.c
===================================================================
--- hw/ide.c	(revision 6296)
+++ hw/ide.c	(working copy)
@@ -2878,8 +2878,28 @@
     printf("%s: 0x%08x\n", __func__, val);
 #endif
     if (!(val & BM_CMD_START)) {
-        /* XXX: do it better */
-        ide_dma_cancel(bm);
+        /*
+	 * We can't cancel Scatter Gather DMA in the middle of the
+	 * operation or a partial (not full) DMA transfer would reach
+	 * the storage so we wait for completion instead (we beahve
+	 * like if the DMA was complated by the time the guest trying
+	 * to cancel dma with bmdma_cmd_writeb with BM_CMD_START not
+	 * set).
+	 *
+	 * In the future we'll be able to safely cancel the I/O if the
+	 * whole DMA operation will be submitted to disk with a single
+	 * aio operation in the form of aio_readv/aio_writev
+	 * (supported by linux kernel AIO but not by glibc pthread aio
+	 * lib).
+	 */
+	if (bm->aiocb) {
+		QEMU_WARN("qemu_aio_flush called");
+		qemu_aio_flush();
+		if (bm->aiocb)
+			QEMU_WARN("aiocb still pending");
+		if (bm->status & BM_STATUS_DMAING)
+			QEMU_WARN("BM_STATUS_DMAING still pending");
+	}
         bm->cmd = val & 0x09;
     } else {
         if (!(bm->status & BM_STATUS_DMAING)) {

[Qemu-devel] Re: [PATCH] ide_dma_cancel will result in partial DMA transfer (resend #3)

[Anthony Liguori]

Andrea Arcangeli wrote:
> +	if (bm->aiocb) {
> +		QEMU_WARN("qemu_aio_flush called");
>   

This doesn't build (there is no QEMU_WARN).  I think I've mentioned this 
before?

Regards,

Anthony Liguori

> +		qemu_aio_flush();
> +		if (bm->aiocb)
> +			QEMU_WARN("aiocb still pending");
> +		if (bm->status & BM_STATUS_DMAING)
> +			QEMU_WARN("BM_STATUS_DMAING still pending");
> +	}
>          bm->cmd = val & 0x09;
>      } else {
>          if (!(bm->status & BM_STATUS_DMAING)) {
>
>   

[Qemu-devel] Re: [PATCH] ide_dma_cancel will result in partial DMA transfer (resend #3)

[Andrea Arcangeli]

On Thu, Feb 26, 2009 at 10:04:13AM -0600, Anthony Liguori wrote:
> Andrea Arcangeli wrote:
>> +	if (bm->aiocb) {
>> +		QEMU_WARN("qemu_aio_flush called");
>>   
>
> This doesn't build (there is no QEMU_WARN).  I think I've mentioned this 
> before?

First patch that triggered some replies didn't have this problem. Must
have been a mistake when resending #2 that didn't generate
replies. This one below should build too.

------
Subject: avoid cancelling ide dma
From: Andrea Arcangeli <aarcange@redhat.com>

The reason for not actually canceling the I/O is because with
virtualization and lots of VM running, a guest fs may mistake a
overload of the host, as an IDE timeout. So rather than canceling the
I/O, it's safer to wait I/O completion and simulate that the I/O has
completed just before the io cancellation was requested by the
guest. This way if ntfs or an app writes data without checking for
-EIO retval, and it thinks the write has succeeded, it's less likely
to run into troubles. Similar issues for reads.

Furthermore because the DMA operation is splitted into many synchronous
aio_read/write if there's more than one entry in the SG table, without this
patch the DMA would be cancelled in the middle, something we've no idea if it
happens on real hardware too or not. Overall this seems a great risk for zero
gain.

This approach is sure safer than previous code given we can't pretend all guest
fs code out there to check for errors and reply the DMA if it was completed
partially, given a timeout would never materialize on a real harddisk unless
there are defective blocks (and defective blocks are practically only an issue
for reads never for writes in any recent hardware as writing to blocks is the
way to fix them) or the harddisk breaks as a whole.

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

Index: hw/ide.c
===================================================================
--- hw/ide.c	(revision 6626)
+++ hw/ide.c	(working copy)
@@ -2983,8 +2983,27 @@
     printf("%s: 0x%08x\n", __func__, val);
 #endif
     if (!(val & BM_CMD_START)) {
-        /* XXX: do it better */
-        ide_dma_cancel(bm);
+        /*
+	 * We can't cancel Scatter Gather DMA in the middle of the
+	 * operation or a partial (not full) DMA transfer would reach
+	 * the storage so we wait for completion instead (we beahve
+	 * like if the DMA was complated by the time the guest trying
+	 * to cancel dma with bmdma_cmd_writeb with BM_CMD_START not
+	 * set).
+	 *
+	 * In the future we'll be able to safely cancel the I/O if the
+	 * whole DMA operation will be submitted to disk with a single
+	 * aio operation with preadv/pwritev.
+	 */
+	if (bm->aiocb) {
+		qemu_aio_flush();
+#ifdef DEBUG_IDE
+		if (bm->aiocb)
+			printf("aiocb still pending");
+		if (bm->status & BM_STATUS_DMAING)
+			printf("BM_STATUS_DMAING still pending");
+#endif
+	}
         bm->cmd = val & 0x09;
     } else {
         if (!(bm->status & BM_STATUS_DMAING)) {