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

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

Hi,

On 10/2/19 7:56 PM, Brian Woods wrote:
> 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...)?
>>
> 
> I did include all the ARM maintainers, although I forgot to CC
> Volodymyr.  Sorry about that.

Hmmm, the first e-mail didn't land in my inbox directly (I have a filter 
send to a separate directory any e-mail I not CCed on). Did you BCC me 
by any change?

>  Also, I'm not sure if this is strictly an
> ARM or general Xen bug so I left ARM.  I guess I should have mentioned
> that in the email though.

Let see try to troubleshoot it first :).

> 
> I prefer having them as attachments due to the fact I can see everything
> in mutt. Although if there's a strong community consensus that logs
> shouldn't be emailed as attachments, I will start using a pastebin like
> service to post them.

Well, any attachment you send on the ML will store to each subscribers 
mailbox. I let you do the math here ;)

So yeah, pastebin is always the preferred way when you have to send the 
full log.

> 
>>>
>>> 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
> 
> Attached are the logs of loading patched Xen at the good and bad
> address.  It appears the MFN has stayed the same, although there's only
> one WARN message for both the good and bad address.

Thank you for the log. So that's probably not a double-init then.

Looking back at the log, the values look quite sane. So I am not 
entirely sure what is happening.

I would check that the frametable is correctly zeroed. You could add a 
print at the end of setup_frametable_mappings(...) to dump the 
count_info for the page. Something like:
      mfn_to_page(_mfn(0x01533))->count_info;

If it is correctly initialized, it should be zero.

The next step would be to add a similar print in start_xen() 
(xen/arch/arm/setup.c) and see where the value is not 0 anymore.

Cheers,

-- 
Julien Grall

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