From patchwork Tue Jul 27 18:35:39 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrea Arcangeli X-Patchwork-Id: 60030 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 9106BB70AE for ; Wed, 28 Jul 2010 04:44:18 +1000 (EST) Received: from localhost ([127.0.0.1]:53068 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Odp2f-0006ix-Au for incoming@patchwork.ozlabs.org; Tue, 27 Jul 2010 14:38:17 -0400 Received: from [140.186.70.92] (port=36061 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Odp0H-00057s-HY for qemu-devel@nongnu.org; Tue, 27 Jul 2010 14:36:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Odp0D-0005v1-G9 for qemu-devel@nongnu.org; Tue, 27 Jul 2010 14:35:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34152) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Odp0D-0005uX-2l for qemu-devel@nongnu.org; Tue, 27 Jul 2010 14:35:45 -0400 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6RIZgwb001400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Jul 2010 14:35:43 -0400 Received: from random.random ([10.3.113.19]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6RIZeac026439; Tue, 27 Jul 2010 14:35:41 -0400 Date: Tue, 27 Jul 2010 20:35:39 +0200 From: Andrea Arcangeli To: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] ide_dma_cancel will result in partial DMA transfer (resend #4) Message-ID: <20100727183539.GN16655@random.random> References: <20100727173050.GK16655@random.random> <4C4F1AFB.3020100@codemonkey.ws> <20100727181522.GM16655@random.random> <4C4F244C.90906@codemonkey.ws> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4C4F244C.90906@codemonkey.ws> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.18 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. Cc: qemu-devel@nongnu.org X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Tue, Jul 27, 2010 at 01:24:12PM -0500, Anthony Liguori wrote: > On 07/27/2010 01:15 PM, Andrea Arcangeli wrote: > > On Tue, Jul 27, 2010 at 12:44:27PM -0500, Anthony Liguori wrote: > > > >> printf()s? > >> > > I see plenty of printf in that file, do you want them only under > > #ifdef DEBUG_IDE? > > > > Yes. Indented with 4 spaces too, but there are tabs, hope that's ok otherwise I need to undo my editor settings optimized for kernel (develock has quite an opinion on the tab/space issue ;). ===== Subject: avoid canceling ide dma From: Andrea Arcangeli 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 Signed-off-by: Andrea Arcangeli --- diff --git a/hw/ide/pci.c b/hw/ide/pci.c index 4331d77..a019e0d 100644 --- a/hw/ide/pci.c +++ b/hw/ide/pci.c @@ -40,8 +40,27 @@ 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(); +#ifdef DEBUG_IDE + 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"); +#endif + } bm->cmd = val & 0x09; } else { if (!(bm->status & BM_STATUS_DMAING)) {