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

Re: [Xen-users] Debugging DomU

On Tue, 2015-04-28 at 17:51 +0000, Chris Brand wrote:
> Hi,
> Iâm trying to get Xen up and running on an embedded processor board. I
> have the hypervisor and Domain0 running fine. I can apparently create
> DomainU VMs, too (they are listed as running in the output from âxl
> listâ), but Iâm not seeing any sort of output from them (console,
> ping, etc). What Iâm wondering is how I can go about debugging this ?
> I tried âxl core-dump 1â, but got âxc: error: Could not get address
> size for domain (38 = Function not implemented) : Internal errorâ.
> From the Xen console, I can see the Dom0 registers and backtrace, but
> I donât see a way to get the same thing for other domains.
> Iâm sure the actual problem Iâm hitting is something stupid that Iâm
> doing wrong, but Iâd like to know how I can figure it out for myselfâ

I'm afraid that many of the usual suspects (e.g. gdbsx) do not work on
ARM yet (AFAIK).

I think xenctx (from $prefix/lib/xen/bin) should work, which will get
you at least register state including, hopefully, a useful r15 which gdb
or addr2line can convert back to a source line in the kernel.

After that I'm afraid it's currently down to things which modify the
guest kernel.

My first goto is usually to insert code to make printk use the
HYPERVISOR_console_io (under Linux by patching in a xen_raw_printk
somewhere), with a debug build of Xen this output then goes to Xen's own

I found [0] in one of my linux.git trees, I'd checked it in so it
probably worked ;-)

If that doesn't help (e.g. because the issue is in early ASM code or
something) then I usually move on to the "hvc 0xfffN" magic debug
opcode, which is available in debug builds only. The "N" in 0xfffN can
be determined from xen.git/xen/arch/arm/traps.c:do_debug_trap. I mostly
use 0xffff which dumps the full vcpu state, but 0xfffe which prints the
character in the low byte of r0 is also useful.



Xen-users mailing list



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