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.
