[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] XEN 4.5, odroid-xu, domU
Hi Suriyan, On 07/21/2014 12:02 PM, Ian Campbell wrote: > 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. I suspect the odroid xu kernel is not multiplatform. In this case you can't reuse the same kernel for DOM0 and the guest. You also need to make sure that CONFIG_ARCH_VIRT=y. Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |