Re: [Xen-devel] XEN 4.5, odroid-xu, domU

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Sun, 2014-07-20 at 10:18 -0700, Suriyan Ramasami wrote:

>    Pursuing further, I am having issues starting a domU kernel. In all
> the documentation I always find the dtb appended to the kernel.

This was the case until about half way through the 4.4 development
cycle. From 4.4 onwards the toolstack will generate a DTB and you should
avoid appending one.

What docs are you looking at which needs updating?

>  I am
> refraining from doing so.
> 
> My domU config file:
> root@odroid-desktop:~# cat vmTest.cfg
> kernel = "/root/zImage.dom0"
> memory = 512
> name = "domuTest"
> vcpus = 1
> disk = [ 'phy:/dev/loop0,xvda,w' ]
> extra = "console=hvc0 root=/dev/xvda debug rw"
> 
> I am using the same kernel which is running as dom0.
> 
> I create domU with: xl create vmTest.cfg
> It creates is fine but then the domU kernel immediately crashes.

This usually indicates that you have CONFIG_DEBUG_LL set to something.
This works in dom0 (where the host platform's UART can be used) but not
for guests which see a purely virtualized physical address space.

> Note that the PC is at 0x0000000c

That's a prefetch abort. What happens is that when DEBUG_LL tries to
access the MMIO region it takes a data abort, to address 0x10. But there
is nothing there, so then you take a prefetch abort to 0xc. There is
nothing there either so the processor just loops taking aborts.

> The link: 
> http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#Common_DomU_Pitfalls
> points at one such case where I could hit the issue. I do not have
> CONFIG_DEBUG_LL set, but looks awefully similar to what is being
> described. So, most probably this is the issue, as I do not see any
> output as well.

Uh, I should clearly have read all the way to the end of your mail
before I commented :-).

If your issue isn't DEBUG_LL then I'm not sure what it could be.

You could try adding calls to xen_raw_printk to the guest kernel's
normal printk routines -- this might get you some earlier debugging
output if you have a debug=y build of Xen.

LR_svc is set to 0x40c569c4 which suggests that might be the original
faulting address, but it looks like it is pre-MMU and with all the
relocation which occurs during boot it might be tricky to find out what
it is.

Last trick I use is to sprinkle "hvc #0xffd" around the guest boot path
asm to see how far it is getting. This needs debug=y, see
traps.c:do_debug_trap for some of the magic immediates which you can
use.

I'm afraid that given the early fault my money is on DEBUG_LL. I suggest
making sure you have done a completely clean build without it.

Ian.


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