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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.01.19 at 18:02, <roger.pau@xxxxxxxxxx> wrote:
> 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.

When filling the gap between an entry aligned no better than 4k,
you unavoidably will need to allocate (and map) at least one
order-0 chunk. If you started with an order-5 one, in the next
iteration the alignment would still be no better than 4k (and hence
you'd never reach an alignment of 2M or 1G)..

> 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.

It would need to make one request with order-0, and then individual
requests with higher orders to incrementally increase alignment. I've
already indicated that I think the function should accept all orders as
inputs, irrespective of underlying hardware capabilities, if it doesn't
already. But that's still not the same as accepting arbitrary counts as
inputs.

Jan



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