Re: [Xen-devel] [PATCH] iommu: specify page_count rather than page_order to iommu_map/unmap()...

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Jan 21, 2019 at 04:27:38AM -0700, Jan Beulich wrote:
> >>> On 18.01.19 at 17:03, <paul.durrant@xxxxxxxxxx> wrote:
> > ...and remove alignment assertions.
> > 
> > Testing shows that certain callers of iommu_legacy_map/unmap() specify
> > order > 0 ranges that are not order aligned thus causing one of the
> > IS_ALIGNED() assertions to fire.
> 
> As said before - without a much better explanation of why the current
> order-based model is unsuitable (so far I've been provided only vague
> pointers into "somewhere in PVH Dom0 boot code" iirc) to understand
> why it's undesirable to simply make those call sites obey to the current
> requirements, I'm not happy to see us go this route.

The current PVH dom0 builder will try to always use the biggest
possible order to populate the physmap.

However, the memory map used by dom0 is not under our control, so it's
quite likely that a RAM region starts at a 4K only aligned address.
dom0 builder will then find the next 2M or 1G aligned address and
populate the space between the current address and the next aligned
address using an order as high as possible. In the above scenario,
it's perfectly fine to populate a 4K aligned entry using an order of 5
for example, in order to reach the next 2M or 1G aligned address.

Not removing the asserts would imply that in the above example the
dom0 builder has to iterate over all the 4K pages and make repeated
guest_physmap_add_page calls with order 0. This is sub-optimal,
creates a non-trivial overhead to the Dom0 builder, and also promotes
the open-coding of loops around guest_physmap_add_page.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel