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

[Brian Woods <brian.woods@xxxxxxxxxx>]

On Wed, Oct 02, 2019 at 08:59:28PM +0100, Julien Grall wrote:
> 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?

That's odd.  I know I copied your and Stefano's email addresses from the
MAINTAINERS file but under my sent emails it shows it has having no
CCs...  PEBCAK I guess.  My apologies.

> > 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@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,
> >>
> >>-- 
> >>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

I'll go ahead add those and see if that leads to anything.

-- 
Brian Woods

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