All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] ide_dma_cancel will result in partial DMA transfer (resend #4)
Date: Tue, 27 Jul 2010 12:44:27 -0500	[thread overview]
Message-ID: <4C4F1AFB.3020100@codemonkey.ws> (raw)
In-Reply-To: <20100727173050.GK16655@random.random>

On 07/27/2010 12:30 PM, Andrea Arcangeli wrote:
> Subject: avoid canceling 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: Izik Eidus<ieidus@redhat.com>
> Signed-off-by: Andrea Arcangeli<aarcange@redhat.com>
> ---
>
> diff --git a/hw/ide/pci.c b/hw/ide/pci.c
> index 780fc5f..9f6d42a 100644
> --- a/hw/ide/pci.c
> +++ b/hw/ide/pci.c
> @@ -40,8 +40,25 @@ void bmdma_cmd_writeb(void *opaque, uint32_t addr, uint32_t val)
>       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 completed 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();
> +		if (bm->aiocb)
> +			printf("ide_dma_cancel: aiocb still pending");
> +		if (bm->status&  BM_STATUS_DMAING)
> +			printf("ide_dma_cancel: BM_STATUS_DMAING still pending");
>    


printf()s?

Regards,

Anthony Liguori

> +	}
>           bm->cmd = val&  0x09;
>       } else {
>           if (!(bm->status&  BM_STATUS_DMAING)) {
>
>
>    

  reply	other threads:[~2010-07-27 17:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-27 17:30 [Qemu-devel] [PATCH] ide_dma_cancel will result in partial DMA transfer (resend #4) Andrea Arcangeli
2010-07-27 17:44 ` Anthony Liguori [this message]
2010-07-27 18:15   ` Andrea Arcangeli
2010-07-27 18:24     ` Anthony Liguori
2010-07-27 18:35       ` Andrea Arcangeli
2010-07-27 18:41         ` Anthony Liguori
2010-07-27 19:04           ` Andrea Arcangeli
2010-07-30  8:02             ` Kevin Wolf
2010-07-27 18:51         ` malc
2010-07-27 18:05 ` malc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C4F1AFB.3020100@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=aarcange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.