Hi Brian,
On 10/3/19 9:24 PM, Brian Woods wrote:
On Thu, Oct 03, 2019 at 07:23:23PM +0000, Julien Grall wrote:
There's a WARN_ON() between the two debug printks calls I shared above.
Looking at the log, the MFN seems to correspond to the one right after
Xen (0000000001400000 - 00000000015328f1) in memory.
So it is normal to have the page given to the boot allocator. However, I
am not entirely sure which bit of init_done() is giving the page again
to xenheap.
It is unlikely to be free_init_memory() because it deal with the init
section that is not at the end of the binary.
This would leave discard_initial_modules() but there are a check to skip
Xen module.
The call stack only print the address and not the symbol because it
unregistered the symbols for init. See unregister_init_virtual_memory().
(XEN) Xen call trace:
(XEN) [<000000000021c1a8>] page_alloc.c#free_heap_pages+0x1a8/0x614 (PC)
(XEN) [<000000000021c1a8>] page_alloc.c#free_heap_pages+0x1a8/0x614 (LR)
(XEN) [<000000000021e900>] page_alloc.c#init_heap_pages+0x3d4/0x564
(XEN) [<000000000021eb24>] init_domheap_pages+0x94/0x9c
(XEN) [<00000000002b83ec>] 00000000002b83ec
(XEN) [<00000000002b8904>] 00000000002b8904
(XEN) [<0000000000260a3c>] setup.c#init_done+0x10/0x20
(XEN) [<00000000002b99ac>] 00000000002b99ac
You should be able to use addr2line on the address with Xen binary.
I have the feeling this will point to discard_initial_modules() as this
is an init function and the symbol should not be printed.
But, I can't see anything obviously wrong in the function... So I am not
entirely sure what could be the next steps.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel