On Wed, 2013-09-25 at 11:36 -0600, Alex Williamson wrote: > On Wed, 2013-09-25 at 17:05 +0100, David Woodhouse wrote: > > Why would it ever care? If it *happens* to map something that can use > > large pages, yay!. If it subsequently breaks apart those large pages by > > unmapping 4KiB in the middle, let the IOMMU driver break that apart. > > Can this be done atomically? I thought part of the reason for this > interface was that iommu drivers typically couldn't replace a huge page > with multiple smaller pages in the presence of DMA.
For the Intel IOMMU it can. You can atomically change from a large page entry, to a pointer to a full set of smaller page tables. Do the IOTLB flush, and at no time is there an interruption in service. Not sure if this is true for *all* IOMMU hardware; I'd be perfectly happy to accept a variant of Jörg's proposal that we should only ever unmap exactly the same range that we mapped. Except we should allow the unmapping of adjacent regions together; just not a partial unmap of something that was mapped in one go. > > Seriously, just the address and the size. Let the IOMMU code deal with > > whether it can *actually* use large pages on the particular set of > > IOMMUs that are in use for the devices you've added to the domain so > > far. > > You're contradicting yourself here. Just let the iommu deal with it, > but now you're raising concerns that Intel may be mixing super page > IOMMU hardware with non-super page IOMMU hardware on the same box, so I > do need to be concerned, yet there's no interface to discover super page > support. No contradiction. Do Not Concern Yourself. Just tell the IOMMU what you want mapped, and where. Let *it* worry about whether it can use superpages or not. Like it already *does*. > What happens if my IOMMU domain makes use of super pages and > then I add a new device behind a new IOMMU without hardware super page > support? Currently, you end up with the domain happily including superpages, and the less capable IOMMU that you added later won't cope. What we probably *ought* to do is walk the page tables and convert any pre-existing superpages to small pages, at the time we add the non-SP-capable IOMMU. FWIW we currently screw up the handling of cache-coherent vs. non-coherent page tables too. That one wants a wbinvd somewhere when we add a non-coherent IOMMU to the domain. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
