Re: [Qemu-devel] [PATCH 08/13] iommu: Introduce IOMMU emulation infrastructure

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2012-05-15 at 17:02 -0500, Anthony Liguori wrote:
> 
> "6.2.1 Register Based Invalidation Interface
> The register based invalidations provides a synchronous hardware interface for 
> invalidations.  Software is expected to write to the IOTLB registers to submit 
> invalidation command and may poll on these registers to check for invalidation 
> completion. For optimal performance, hardware implementations are recommended to 
> complete an invalidation request with minimal latency"
> 
> This makes perfect sense.  You write to an MMIO location to request invalidation 
> and then *poll* on a separate register for completion.
> 
> It's not a single MMIO operation that has an indefinitely return duration.

Sure, it's an implementation detail, I never meant that it had to be a
single blocking register access, all I said is that the HW must provide
such a mechanism that is typically used synchronously by the operating
system. Polling for completion is a perfectly legit way to do it, that's
how we do it on the Apple G5 "DART" iommu as well.

The fact that MMIO operations can block is orthogonal, it is possible
however, especially with ancient PIO devices.

In our case (TCEs) it's a hypervisor call, not an MMIO op, so to some
extent it's even more likely to do "blocking" things.

It would have been possible to implement a "busy" return status with the
guest having to try again, unfortunately that's not how Linux has
implemented it, so we are stuck with the current semantics.

Now, if you think that dropping the lock isn't good, what do you reckon
I should do ?

Cheers,
Ben.