Re: XEN 4.5, odroid-xu, domU

[Julien Grall <julien.grall@linaro.org>]

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