[PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
From: Ohad Ben-Cohen <hidden>
Date: 2011-10-17 09:56:19
Also in:
kvm, linux-omap, lkml
On Mon, Oct 17, 2011 at 11:28 AM, Roedel, Joerg [off-list ref] 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.