Re: [Xen-devel] Errors with Loading Xen at a Certain Address

[Julien Grall <julien.grall@arm.com>]

Sorry I forgot to CC xen-devel back.

On 10/2/19 5:52 PM, Julien Grall wrote:
> 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@arm.com>
>> 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,
> 

-- 
Julien Grall

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