On 17 November 2017 at 12:15, Volodymyr Babchuk <vlad.babc...@gmail.com> wrote: > Hi Jayadev, > > On 17 November 2017 at 13:53, Andrii Anisov <andrii_ani...@epam.com> wrote: >>> >>> Is there a way to debug which one of the above two possibilities has lead >>> to the issue ? >> >> Four years ago I did it in a following way: >> - wire up to UART2 pins on an expansion connector (this sheet might be >> useful for you: http://www.ti.com/lit/ug/swcu130/swcu130.pdf) >> - assign UART2 IOMEM ranges to DomU >> - enable in domu kernel earlyprintk and patch it to output to omap UART2 >> >> Nowadays assigning UART2 IOMEM ranges might be a bit more complex due to XEN >> evolution. >> >> Another way is to use JTAG which understands virtualization, and allows you >> to debug DomU. > I want to add some debugging techniques: > - By tapping CTRL+A three times to switch to XEN console. Then `d` > will show you CPU register states. You will be able to see where your > DomU executes right now. This can help along with addr2line, objdump > and other tools. > > - You can modify traps.c in XEN to crash domain when SMC instruction > is trapped. Then you can put SMC invocation into various parts of > kernel code, to see if it reaches that place. This can help on early > stages, when console is not available.
No need for modifying the Xen. Xen already provides debug facilities when CONFIG_DEBUG=y. You can have a look at do_debug_trap. The ones you likely want are: - hvc 0xffff will show the state of the vCPU - hvc 0xfffe will print the PC Cheers, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
