On 15/01/2019 10:27, Roger Pau Monné wrote: > On Tue, Jan 15, 2019 at 03:16:01AM -0700, Jan Beulich wrote: >>>>> On 15.01.19 at 10:44, <paul.durr...@citrix.com> wrote: >>>> -----Original Message----- >>> [snip] >>>>>> (XEN) Xen call trace: >>>>>> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176 >>>>>> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220 >>>>>> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e >>>>>> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14 >>>>>> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830 >>>>>> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55 >>>>>> (XEN) >>>>>> (XEN) >>>>>> (XEN) **************************************** >>>>>> (XEN) Panic on CPU 0: >>>>>> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at >>>> iommu.c:323 >>>>>> (XEN) **************************************** >>>>> Oh, this was added by Paul quite recently. You seem to be using a >>>>> rather old commit (a5b0eb3636), is there any reason for using such an >>>>> old baseline? >>>> I was using the master branch. Your patch below did fix this issue. >>> Given this failure and the fact that valid orders differ between different >>> architectures, I propose we change the argument to the iommu_map/unmap >>> wrapper functions from an order to a count, thus making it clear that there >>> is no alignment restriction. >> But the whole idea is for there to be an alignment restriction, such >> that it is easy to determine whether large page mappings can be >> used to satisfy the request. What's the exact case where a caller >> absolutely has to pass in a mis-aligned (dfn,size) tuple? > Taking PVH Dom0 builder as an example, it's possible to have a RAM > region that starts on a 4K only aligned address. The natural operation > in that case would be to try to allocate a memory region as big as > possible up to the next 2MB boundary. Hence it would be valid to > attempt to populate this 4K only aligned address using an order > 0 > and < 9 (2MB order). The alternative here if the asserts are not > removed would be to open-code a loop in the caller that iterates > creating a bunch of order 0 mappings up to the 2MB boundary. The > overhead in that case would be quite big, so I don't think we want to > go down that route (also we would end up with a bunch of loops in the > callers).
Given the PVH Dom0 building issues which Roger and I worked on over the Christmas period, there is a human-noticeable difference in construction time when the caller is doing a loop over order 0 pages, vs an order 8 allocation, and that was for a total of 4Mb of RAM. A dfn/count interface is actually more flexible than a dfn/order, because it doesn't require the caller to know the superpage orders of the underlying implementation to create efficient mappings. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
