On 02/07/2010 12:50 PM, Joerg Roedel wrote:
On Sun, Feb 07, 2010 at 11:38:30AM +0200, Avi Kivity wrote:
On 01/28/2010 01:37 PM, Joerg Roedel wrote:
These two functions provide support for mapping and
unmapping physical addresses to io virtual addresses. The
difference to the iommu_(un)map_range() is that the new
functions take a gfp_order parameter instead of a size. This
allows the IOMMU backend implementations to detect easier if
a given range can be mapped by larger page sizes.
These new functions should replace the old ones in the long
term.
These seem to be less flexible in the long term. Sure, it is easier for
the backend to map to multiple page sizes if your iommu supports
arbitrary power-of-two page sizes, but we should make the APIs easier
for the callers, not the backend.
These functions are as flexible as the old ones which just tok a size.
The benefit of the new interface is that is makes the ability of the
IOMMU to map the area with a large page (an get the benefit of fewer
hardware tlb walks) visible to the caller. With the old interface the
caller is tempted to just map ist whole area using 4kb page sizes.
It gives a bit more complexity to the caller, thats right. But given
that the page allocator in Linux always returns pages which are aligned
to its size takes a lot of that complexity away.
You are right - I was thinking of the kvm use case which is range
oriented, but the ordinary kernel interfaces are gfp_order oriented.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
