From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh4yB-0006vp-Vr for qemu-devel@nongnu.org; Tue, 19 Jun 2012 16:24:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sh4yA-00068O-8C for qemu-devel@nongnu.org; Tue, 19 Jun 2012 16:24:11 -0400 Received: from gate.crashing.org ([63.228.1.57]:44261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh4y9-00068K-VE for qemu-devel@nongnu.org; Tue, 19 Jun 2012 16:24:10 -0400 Message-ID: <1340137438.28143.28.camel@pasglop> From: Benjamin Herrenschmidt Date: Wed, 20 Jun 2012 06:23:58 +1000 In-Reply-To: <4FE081CE.1060001@redhat.com> References: <1340087992-2399-1-git-send-email-benh@kernel.crashing.org> <1340087992-2399-8-git-send-email-benh@kernel.crashing.org> <4FE081CE.1060001@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 07/13] usb: Convert usb_packet_{map, unmap} to universal DMA helpers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, anthony@codemonkey.ws, David Gibson On Tue, 2012-06-19 at 15:42 +0200, Gerd Hoffmann wrote: > Well, that isn't guaranteed ... > > > - otherwise the guest > > might invalidate IOMMU mappings while they are still in use by the device > > code. > > Guest tearing down mapping while usb packets using them are still in > flight would be a guest bug. Still not impossible to happen though. How > is this case supposed to be handled? Like with any other device, it's hard ... what would happen on real hardware is that the USB controller will get a target abort, which will result in the controller reporting an error (typically in the PCI status register) and stopping. In qemu we tend not to deal with DMA failures at all. If the scenario above happens, we will potentially continue accessing the guest memory after it has been unmapped. While this is bad, in practice, it's not a huge deal because the USB controller is only accessed by the guest kernel so it's a matter of the guest kernel shooting itself in the foot. So we don't have to fix it as a pre-req to merging the patches, though it would be nice if we did in the long run. The way to fix it is to register a cancel callback (dma_memory_map_with_cancel), which will be called by the iommu code when the translation is invalidated, and which can be used to cancel pending transactions etc... and generally prevent further access to the memory. However the current implementation never calls cancel. Cheers. Ben.