Re: [Xen-devel] About arm32 address translation

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-10-16 at 18:47 +0800, Chen Baozi wrote:
> On Oct 16, 2013, at 6:41 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> > On Wed, 2013-10-16 at 18:26 +0800, Chen Baozi wrote:
> >> On Wed, Oct 16, 2013 at 11:24:47AM +0100, Ian Campbell wrote:
> > 
> >>> That suggests that the guest's SP doesn't have a mapping in the guest's
> >>> PTs. What's the full trace?
> >> 
> >> See http://pastebin.com/DYL5gkAQ
> > 
> > Yeah, not a whole lot to go on is there ;-)
> > 
> > Converting the PC (c02c1544) to a code line with gdb or addr2line would
> > be a good start I think.
> 
> Hmmm, I've posted a mail about this yesterday. The addr2line points
> 0xc021544 to __loop_delay in arch/arm/lib/delay-loop.S of linux
> kernel.

Oh, so maybe this is just a CPU sitting in the idle loop. Odd that the
stack isn't valid, not sure why that would be. You could make
gvirt_to_maddr log the failed PAR register which we could then decode
using the manual.

You could also try dump_guest_s1_walk() to see if the guest PTs make
sense.

It is likely to be stuck in the idle loop because it is waiting for some
device to fire an interrupt. Getting some console logging might help
determine which device that is.

> 
> > 
> > You could also consider hacking up an earlyprintk via Xen by dropping a
> > xen_raw_console_write into vprintk_emit once the buffer is formatted and
> > see if that gets you any useful console output.
> 
> Ok, I'll have a try.
> 
> Thanks.
> 
> Baozi
> 
> > 
> > (Somebody really needs to make a patch for proper Xen capable
> > earlyprintk for arm...)
> > 
> > Ian.
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel