[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] XEN 4.5, odroid-xu, domU
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |