From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHSFg-0002mE-Gl for qemu-devel@nongnu.org; Wed, 13 Aug 2014 02:41:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHSFZ-0006dm-PI for qemu-devel@nongnu.org; Wed, 13 Aug 2014 02:41:40 -0400 Received: from isrv.corpit.ru ([86.62.121.231]:57199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHSFZ-0006ch-Ia for qemu-devel@nongnu.org; Wed, 13 Aug 2014 02:41:33 -0400 Message-ID: <53EB089B.6080906@msgid.tls.msk.ru> Date: Wed, 13 Aug 2014 10:41:31 +0400 From: Michael Tokarev MIME-Version: 1.0 References: <20140812193530.70d0aa63@natsu> <53EA28DB.8060807@msgid.tls.msk.ru> <53EB003F.9000303@msgid.tls.msk.ru> In-Reply-To: <53EB003F.9000303@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Bug#757927: [qemu-kvm] TRIM (discard=unmap) broken in 2.1 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel Cc: Kevin Wolf , Markus Armbruster [dropping debian bugreport] 13.08.2014 10:05, Michael Tokarev wrote: > [This is http://bugs.debian.org/757927 -- trim stopped working in qemu 2.1] > > 12.08.2014 18:46, Michael Tokarev wrote: >> 12.08.2014 17:35, Roman Mamedov wrote: >>> Package: qemu-kvm >>> Version: 2.1+dfsg-2~bpo70+2 >>> Severity: normal >>> >>> Hello, >>> >>> I was able to successfully use the passthrough TRIM support with an IDE >>> interface virtual disk in Qemu-KVM version 2.0. >>> >>> However after upgrading to 2.1 and restarting my VM, TRIM now fails in it with >>> messages like those quoted below (dmesg from the guest). There are no messages >>> in dmesg related to that on the host. > > BTW, I found a system here with an SSD which supports discard, and tried my > guests against it -- everything works fine when I use sata/ahci, but it breaks > indeed when using the default IDE interface. > > But applying the oneliner: > >> It is the same as 2.1+dfsg-1~bpo70+2 but with a one-line patch >> added: >> >> diff --git a/hw/ide/core.c b/hw/ide/core.c >> index db191a6..7256592 100644 >> --- a/hw/ide/core.c >> +++ b/hw/ide/core.c >> @@ -688,7 +688,8 @@ void ide_dma_cb(void *opaque, int ret) >> sector_num, n, s->dma_cmd); >> #endif >> >> - if (!ide_sect_range_ok(s, sector_num, n)) { >> + if ((s->dma_cmd == IDE_DMA_READ || s->dma_cmd == IDE_DMA_WRITE) && >> + !ide_sect_range_ok(s, sector_num, n)) { >> dma_buf_commit(s); >> ide_dma_error(s); >> return; > > fixes the prob for me. So apparently kwolf was right pointing to that > commit 58ac3211. But this makes me wonder: why the issue only exists with ide, but not with ahci/sata? The two should be sufficiently similar to trigger this check the same way. Maybe we have another bug somewhere, like adding an extra sector in some path, which is triggered by 58ac3211? Maybe even in the guest kernel (but in this case, since it works with real hw, we should ignore it). Thanks, /mjt