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

[Julien Grall <julien.grall@xxxxxxx>]

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

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