From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36916 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OekYM-0004hx-VW for qemu-devel@nongnu.org; Fri, 30 Jul 2010 04:02:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OekYL-00080N-UD for qemu-devel@nongnu.org; Fri, 30 Jul 2010 04:02:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33029) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OekYL-000805-NH for qemu-devel@nongnu.org; Fri, 30 Jul 2010 04:02:49 -0400 Message-ID: <4C528723.5020805@redhat.com> Date: Fri, 30 Jul 2010 10:02:43 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] ide_dma_cancel will result in partial DMA transfer (resend #4) References: <20100727173050.GK16655@random.random> <4C4F1AFB.3020100@codemonkey.ws> <20100727181522.GM16655@random.random> <4C4F244C.90906@codemonkey.ws> <20100727183539.GN16655@random.random> <4C4F2848.9040304@codemonkey.ws> <20100727190436.GP16655@random.random> In-Reply-To: <20100727190436.GP16655@random.random> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: qemu-devel@nongnu.org Am 27.07.2010 21:04, schrieb Andrea Arcangeli: > 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 Thanks, applied to the block branch. Kevin