On 10/2/19 1:32 AM, Brian Woods wrote:
Hello,
Hi Brian,
Thank you for report.
I guess this Arm specific, right? If so, please try to CC
the relevant maintainers and possibly add "arm" in the
subject to avoid any delay (Xen-Devel has quite an high
volume of e-mail!).
May I also ask to avoiding sending attachment on the mailing
list and instead upload the log somewhere (e.g. pastebin,
your own webserver...)?
While testing some things out, I found a possible bug in Xen. Xen would
successfully run when loaded (from u-boot) at some addresses but not
others. I didn't observe this issue in 4.11 stable, so I did a bisect
and found that:
commit f60658c6ae47e74792e6cc48ea2effac8bb52826
Author: Julien Grall <julien.grall@xxxxxxx>
Date: Tue Dec 18 13:07:39 2018 +0000
xen/arm: Stop relocating Xen
was what was causing it to fail when it was loaded to that certain
address.
This patch is basically changing how Xen is using the
physical address space. So it exercise more part of Xen
code and most likely a red-herring :).
However, the logs are quite interesting:
(XEN) pg[0] MFN 01533 c=0x180000000000000 o=0 v=0x7ffff t=0
If I am not mistaken, the page state is PGC_state_free.
So this seems to suggest that the page were already
handed over to the allocator.
Would you mind to apply the patch below and paste the log?
Hopefully, you see see two WARN_ON() before Xen is crashing.
Note the patch is assuming the MFN will stay the same after
the patch has been applied. If not, you may need to slightly
tweak it.
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7cb1bd368b..4bf0dbc727 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1389,6 +1389,9 @@ static void free_heap_pages(
for ( i = 0; i < (1 << order); i++ )
{
+
+ WARN_ON(mfn_x(page_to_mfn(pg + 1)) == 0x01533);
+
/*
* Cannot assume that count_info == 0, as there are some corner cases
* where it isn't the case and yet it isn't a bug:
Cheers,
