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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Roger Pau Monne
> Sent: 15 January 2019 08:18
> To: Chao Gao <chao.gao@xxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Subject: Re: [Xen-devel] an assertion triggered when running Xen on a HSW
> desktop
> 
> On Tue, Jan 15, 2019 at 04:04:40PM +0800, Chao Gao wrote:
> [...]
> > (XEN) Xen version 4.12-unstable (root@) (gcc (Ubuntu 7.3.0-
> 27ubuntu1~18.04) 7.3.0) debug=y  Tue Jan 15 07:25:29 UTC 2019
> > (XEN) Latest ChangeSet: Mon Dec 17 09:22:59 2018 +0000 git:a5b0eb3636
> [...]
> > (XEN) *** Building a PVH Dom0 ***
> > (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
> iommu.c:323
> > (XEN) ----[ Xen-4.12-unstable  x86_64  debug=y   Tainted:  C   ]----
> > (XEN) CPU:    0
> > (XEN) RIP:    e008:[<ffff82d08025ccbc>] iommu_map+0xba/0x176
> > (XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor
> > (XEN) rax: 0000000000000000   rbx: 0000000000000007   rcx:
> 0000000000000003
> > (XEN) rdx: 000000000020f081   rsi: 0000000000000001   rdi:
> ffff830215242000
> > (XEN) rbp: ffff82d080497bb8   rsp: ffff82d080497b58   r8:
> 0000000000000000
> > (XEN) r9:  ffff82d080497bd4   r10: 0180000000000000   r11:
> 7fffffffffffffff
> > (XEN) r12: ffff830215242000   r13: 0000000000000000   r14:
> 0000000000000001
> > (XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4:
> 00000000001526e0
> > (XEN) cr3: 00000000dbc8d000   cr2: 0000000000000000
> > (XEN) fsb: 0000000000000000   gsb: 0000000000000000   gss:
> 0000000000000000
> > (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> > (XEN) Xen code around <ffff82d08025ccbc> (iommu_map+0xba/0x176):
> > (XEN)  41 89 c5 e9 a2 00 00 00 <0f> 0b 0f 0b 41 89 c5 41 80 bc 24 c0 01
> 00 00 00
> > (XEN) Xen stack trace from rsp=ffff82d080497b58:
> > (XEN)    0000000000000020 0000000000000000 ffff82d080497ba8
> ffff82d08023d489
> > (XEN)    0000000000000001 ffff82e0041e1000 ffff830215242000
> ffff82e0041e1020
> > (XEN)    ffff830215242000 0000000000000000 0000000000000001
> 0000000000000001
> > (XEN)    ffff82d080497c08 ffff82d0804182d8 ffff82d080497c08
> 0000000100000000
> > (XEN)    000000000000009d 0000000000000000 0000000000000001
> ffff82d080444c68
> > (XEN)    000000000020b43e ffff830215242000 ffff82d080497d58
> ffff82d08043716c
> > (XEN)    ffff82d080497fff 0000000100000000 ffff82d08046cbc0
> ffff83000009bf40
> > (XEN)    0000000001e33000 ffff83000009bf30 ffff830213525000
> 000000000010b43e
> > (XEN)    ffff82d00000000b 00000000000001f4 0000000000100000
> 0000001f15242000
> > (XEN)    00ff82d080497cb8 ffff82d08020a8e4 ffff82d0805cf02c
> ffff82d08048f740
> > (XEN)    0000000000000092 ffff82d08023dddb ffff82d080497fff
> ffff82d08048f740
> > (XEN)    ffff82d080497cc8 ffff82d08023de2e ffff82d080497ce8
> ffff82d08024016b
> > (XEN)    ffff82d080497ce8 ffff82d08023de78 ffff82d080497d08
> ffff82d080240205
> > (XEN)    ffff82d0805a3880 ffff82d0805a3880 ffff82d080497d48
> ffff82d08023d489
> > (XEN)    ffff8302152e1550 ffff83000009bf30 0000000001e33000
> ffff83000009bf30
> > (XEN)    0000000001e33000 ffff83000009bf40 ffff82d08046cbc0
> ffff830215242000
> > (XEN)    ffff82d080497d98 ffff82d08043e53c ffff82d080497d98
> ffff82d08046cbc0
> > (XEN)    ffff8302152e1550 0000000000000001 ffff82d0805d00d0
> 0000000000000008
> > (XEN)    ffff82d080497ee8 ffff82d08042d8ef 0000000000000000
> 0000000000000002
> > (XEN)    0000000000000002 0000000000000002 0000000000000002
> 0000000000000002
> > (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?
> 
> In order to fix this you likely need to update your base changeset to
> something newer that contains:
> 
> commit ae7fc10d2ca5c22e04b8a28becbd1fbf8b44e83a
> Author: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> Date:   Fri Dec 28 12:18:56 2018 +0100
> 
>     x86/dom0: take alignment into account when populating p2m in PVH mode
> 
>     Current code that allocates memory and populates the p2m for PVH Dom0
>     doesn't take the address alignment into account, this can lead to high
>     order allocations that start on a non-aligned address to be broken
>     down into lower order entries on the p2m page tables.
> 
>     Fix this by taking into account the p2m page sizes and alignment
>     requirements when allocating the memory and populating the p2m.
> 
> AFAICT the above commit should fix the issue, just updating to current
> staging branch should be enough.
> 
> Paul, I wonder however whether the ASSERT is expected here, this
> interface used to work correctly without the alignment requirements,
> and 725bf00a8 changed the requirements of the function, which might
> make some previously valid calls now trigger the assert. FTR I agree
> we should use aligned regions, but the addition of the assert can be
> dangerous given it changes the valid inputs of the function and also
> affects the p2m functions that ultimately call the iommu code.

Well, no-one should really be passing an arbitrary order into any function so 
we need to catch whatever it is. XenServer has a similar issue so I'll be 
investigating that shortly.

  Paul

> 
> Thanks, Roger.

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