Re: [PATCH] On unmap, flush IOMMU TLB and return correct size

[David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2450 bytes --]

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

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]