[PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware

[Ohad Ben-Cohen]

On Mon, Oct 17, 2011 at 11:28 AM, Roedel, Joerg <Joerg.Roedel at amd.com> wrote:
> The patch looks good now. Please implement option a) and it should be
> fine.

Ok, will send in a few moments.

> I will test it on an AMD IOMMU platform. We still need someone to
> test it on VT-d.

That could be great, yeah.

Though by declaring variable-size page sizes support, we intentionally
take a very conservative approach which should effectively make this
whole logic transparent to both of the x86 implementations:

The ->map() handler of both of the AMD driver and the VT-d should be
invoked in the exact way it was invoked earlier (same order, same
parameters), because before this patch-set, all IOMMU users only
mapped page-ordered regions. With this patch-set in hand, the x86
drivers declare support for all possible page-ordered page sizes, so
the IOMMU core should just be a pass-through, and call ->map() with
the exact parameters that were provided to iommu_map().

Similarly, calls to ->unmap() should not change, because current
mainline x86 users (kvm..) only unmap a single page at a time. With
this patch set in hand, the iommu core will just trivially pass those
request through to the driver's ->unmap().

So I guess that if we can test this on AMD and see that indeed this
conservative approach works (the driver gets the same ->map() and
->unmap() calls it got before) then it should work exactly the same
with VT-d.

But having someone with a VT-d setup to test this can be great of course.

Thanks,
Ohad.