> -----Original Message----- > From: Roger Pau Monne > Sent: 15 January 2019 08:18 > To: Chao Gao <chao....@intel.com> > Cc: xen-devel@lists.xenproject.org; Paul Durrant <paul.durr...@citrix.com> > 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....@citrix.com> > 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel