On Wed, Jun 20, 2012 at 06:23:58AM +1000, Benjamin Herrenschmidt wrote:
> 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.
So, in fact the original comment is a bit out of date. With the
current version of this series, then a guest attempt to invalidate
will be delayed until the unmap occurs. If we discover that leads to
delays which are too long then we can add the cancel callback to
handle this. However, the USB case should be ok - it may not be
theoretically guaranteed that the calls are close, but it's certainly
the case at the moment.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
