Re: [Xen-devel] an assertion triggered when running Xen on a HSW desktop

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 15 January 2019 10:53
> To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
> Cc: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; Roger Pau Monne
> <roger.pau@xxxxxxxxxx>; Chao Gao <chao.gao@xxxxxxxxx>; xen-devel <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] an assertion triggered when running Xen on a HSW
> desktop
> 
> >>> On 15.01.19 at 11:42, <andrew.cooper3@xxxxxxxxxx> wrote:
> > 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.Durrant@xxxxxxxxxx> 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.
> 
> The caller not having to know the implementation supported
> super page orders is pretty desirable indeed. But afaics
> iommu_map() already allows for this, and even if it didn't this
> would not require switching from order to count as function
> parameter.

I guess the question is whether we want to allow arbitrary alignment of the 
memory passed into iommu_map() or not. If we do then I think a count parameter 
makes more sense.

  Paul

> 
> Jan

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