Messages in this thread | | | From | Ohad Ben-Cohen <> | Date | Mon, 17 Oct 2011 11:55:53 +0200 | Subject | Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware |
| |
On Mon, Oct 17, 2011 at 11:28 AM, Roedel, Joerg <Joerg.Roedel@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.
| |