]> git.ipfire.org Git - thirdparty/qemu.git/commit
ide: Avoid canceling IDE DMA
authorAndrea Arcangeli <aarcange@redhat.com>
Tue, 27 Jul 2010 19:04:36 +0000 (21:04 +0200)
committerKevin Wolf <kwolf@redhat.com>
Tue, 3 Aug 2010 14:39:54 +0000 (16:39 +0200)
commit96638e706cd431528690cf611adcb04e1bc3255d
tree5b7f665b9d2f15e04635dcb212c4356ded8cd8ed
parent08e90b3cadfa7ce83efe45e7f211dd868fd8bf27
ide: Avoid canceling IDE DMA

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>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 953844d102f5b682f0835f021f2ed2ad9fb7734c)
hw/ide/pci.c