Re: [Xen-users] Debugging DomU

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2015-05-26 at 11:08 +0200, Julien Grall wrote:
> Hi Ian,
> 
> On 26/05/2015 11:03, Ian Campbell wrote:
> > On Tue, 2015-05-26 at 10:48 +0200, Julien Grall wrote:
> >>> 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.
> >>
> >> I confirm the CONFIG_DEBUG_LL should be disabled in Xen guest because
> >> it's not portable and not supported.
> >
> > So long as it is configured to use the same underlying device as Xen's
> > console then it shouldn't result in crashes, I thought, due to the very
> > simplistic uart stuff in xen/arch/arm/vuart.c.
> 
> For dom0 yes. But we are talking about domU here.

Ah yes, I hadn't paged in all the context of this thread, sorry.

> The UART emulated by vuart.c re-uses the hardware UART region. In domU, 
> this region may clash with other part of the memory layout. Therefore 
> it's not possible to use it.

Right.

/me wonders about a once-per-domain warning when an MMIO trap occurs to
what would be the vuart address if it were available... Would save a lot
of hair pulling (and if it happens to be ram we miss the trap, but
that's fine)

Ian.


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