Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

[Peng Fan <van.freenix@xxxxxxxxx>]

Hi,

On 6/18/2015 10:54 PM, Ian Campbell wrote:
> On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote:
> > Hi,
> >
> > I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
> > no clear idea about why Dom0 kernel panic.
> Have you confirmed that this same kernel runs reliably natively on this
> platform?
Yeah. With XEN related configuration, the kernel can run natively on the 
platform.
> [...]
> > / # Unable to handle kernel NULL pointer dereference at virtual address
> > 00000000
> > pgd = 84f1c000
> > [00000000] *pgd=8cf15831, *pte=00000000, *ppte=00000000
> > Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
> > Modules linked in:
> > CPU: 0 PID: 89 Comm: sh Not tainted 3.14.28-01780-g281e5c1-dirty #269
> > task: 84c07a80 ti: 84f02000 task.ti: 84f02000
> > PC is at 0x0
> > LR is at call_timer_fn.isra.33+0x24/0x88
> > pc : [<00000000>]    lr : [<80038b38>]    psr: 20000113
> Your kernel has jumped to address 0x0 for some reason. You should use
> gdb or something to examine you vmlinux file and try and figure out what
> LR is doing, which may give you a hint as to why it is apparently
> jumping to address zero.
I add such piece of code the linux kernel version 3.14.38. The panic 
disappears.
diff --git a/kernel/timer.c b/kernel/timer.c
index 38f0d40..4a025cc 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base 
*base)
                        base->running_timer = timer;
                        detach_expired_timer(timer, base);
+                       if (!fn) {
+                               printk("fn is null why????\n"); ----> 
This log only shows once. Not sure why fn is null and only once.
+                               continue;
+                       }

                        if (irqsafe) {
                                spin_unlock(&base->lock);
> > (XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty
> What changes have you made to your version of Xen? c01e139 is not an
> upstream commit.
I only add an uart driver and a platform file. The platform part is very 
simple:
PLATFORM_START(imx7d, "i.MX 7Dual")
    .compatible = imx7d_dt_compat,
    .smp_init = imx7d_smp_init,  --> Actually I disabled this, since in 
dts, only one cpu node enabled.
    .cpu_up = cpu_up_send_sgi,
    /* Use IRAM base, not sure */
#if 0
    .dom0_gnttab_start = 0x00900000,
    .dom0_gnttab_size = 0x20000,
#endif
PLATFORM_END
> > I am not sure whether this realted to timer, the timer dts:
> I think it looks like a software timer thing in the kernel rather than a
> h/w timer thing.
>
> > The Dom0 kernel is also configured with " CONFIG_ARM_ARCH_TIMER=y", will
> > this incur errors? Or should Dom0 kernel not use arm arch timer?
> Guests on Xen (including dom0) _should_ be using the arch timer.
>
> Ian.
Not sure whether it relates to the uart driver that Julien suspected. 
But after apply the above kernel patch, Dom0 Linux can handle shell input.
Just have another question, How can Dom0 handle DMA for arm.

Thanks,
Peng.

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