[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Debugging DomU


  • To: Julien Grall <julien.grall@xxxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>
  • From: "Chris (Christopher) Brand" <chris.brand@xxxxxxxxxxxx>
  • Date: Mon, 25 May 2015 23:10:03 +0000
  • Accept-language: en-US
  • Cc: xen-users <xen-users@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 25 May 2015 23:11:24 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>
  • Thread-index: AdCB2wWZcr9SQU3CS2ODe9QE3SnJMACfCemAAAUH66AAIWukAACjOORwACWVbwABa+9kIAAqoyMAAAGcR8AAL4ylAAEI4IqwAIsLYwAAZrncAA==
  • Thread-topic: [Xen-users] Debugging DomU

Hi Julien,

>Currently Xen use a dummy implementation of Debug registers which let the 
>guest think it's not possible to use hardware debugging.
>
>Although, it looks like we miss some registers when it was implemented.
>
>AFAICT DBDGDTRTXint register should be handled WI/RAZ. Can you give a try to 
>the patch below?

The patch you provided does make the message go away.

I can actually step reliably through the startup code with the JTAG now. It 
looks like that instruction was from the "putstr("Decompressing kernel...");" 
in arch/arm/boot/compressed/misc.c.
With that change, xenctx shows me a much more reasonable value for PC and 
SVC_LR. Digging around then led me to disable CONFIG_DEBUG_LL, because it seems 
that the problems I'm seeing relate to trying to print something. With that, I 
think it's getting further still. Xenctx now tells me that it ends up in 
__loop_delay(), with LR pointing to panic(). I'm having problems reproducing 
this with the JTAG, though (it seems to behave slightly differently when I'm 
using JTAG to debug it), and I'm not seeing any output from DomU.

Chris


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.