From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: About arm32 address translation Date: Wed, 16 Oct 2013 12:01:24 +0100 Message-ID: <1381921284.21901.75.camel@kazak.uk.xensource.com> References: <1381915521.21901.54.camel@kazak.uk.xensource.com> <2D233787-D3A5-48D2-9398-C122CB57C187@gmail.com> <1381919087.21901.64.camel@kazak.uk.xensource.com> <20131016102658.GA6871@cbz-workstation> <1381920078.21901.68.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Chen Baozi Cc: List Developer Xen List-Id: xen-devel@lists.xenproject.org On Wed, 2013-10-16 at 18:47 +0800, Chen Baozi wrote: > On Oct 16, 2013, at 6:41 PM, Ian Campbell 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. > > >