your change "iommu: make map and unmap take a page count, similar to flush"

[Jan Beulich <jbeulich@xxxxxxxx>]

Paul,

the description of this says

"At the moment iommu_map() and iommu_unmap() take a page order rather than a
 count, whereas iommu_iotlb_flush() takes a page count rather than an order.
 This patch makes them consistent with each other, opting for a page count since
 CPU page orders are not necessarily the same as those of an IOMMU."

I don't understand the latter sentence at all, now that I read it again.
What may differ is the base page size, but that affects counts of pages
and page order all the same.

I'm intending to make an attempt to cut through the page order (or
count) to the actual vendor functions, in order to then be able to
establish large page mappings where possible. In all cases (perhaps
most noticable on Arm) handing them a page order would seem easier, so
I was considering to have iommu_{,un}map() do that step of abstraction
(or transformation). But since you did explicitly convert from order to
count, I was wondering whether me following this plan would cause
problems with any of your further intentions back then.

If we really wanted to cater for base page size varying between CPU and
IOMMU, besides the IOMMU vendor code needing to announce their value, I
guess we'd have to do quite a bit more abstracting work, as it would
matter to outer layers in particular if the IOMMU base page size was
larger than the CPU's. Supporting just smaller IOMMU base page sizes,
otoh, would seem entirely feasible to deal with inside the rework of
iommu_{,un}map() as mentioned above.

Jan