Re: [Xen-devel] Domain 0 crashed when booting OMAP5 uEVM

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 15 August 2013 10:47, Chen Baozi <baozich@xxxxxxxxx> wrote:
> On Thu, Aug 15, 2013 at 10:13:15AM +0100, Julien Grall wrote:
>> On 14 August 2013 13:38, Chen Baozi <baozich@xxxxxxxxx> wrote:
>> >
>> > On Aug 14, 2013, at 5:55 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
>> >
>> >> On 14 August 2013 10:46, Chen Baozi <baozich@xxxxxxxxx> wrote:
>> >>>
>> >>> On Aug 13, 2013, at 5:58 PM, Julien Grall <julien.grall@xxxxxxxxxx> 
>> >>> wrote:
>> >>>
>> >>>> On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@xxxxxxxxxxxxxxx> 
>> >>>> wrote:
>> >>>>> disable printings from LK decompressor (it writes directly to omap 
>> >>>>> debug
>> >>>>> UART3, and if you give it to xen and don't map to Dom0 - will have data
>> >>>>> abort)
>> >>>>
>> >>>> With Chen's patch series and the latest Xen, you don't need to disable
>> >>>> LK decompressor.
>> >>>> Xen has a basic emulation for "stolen" UART.
>> >>>
>> >>> BTW, does it mean that we don't need to set the UART status "disabled" 
>> >>> in DTS?
>> >>
>> >> Unfortunately, no. The UART emulation is too simple to handle the real 
>> >> driver.
>> >> I'm currently preparing a patch series which will remove this hack in the 
>> >> DTS.
>> >
>> > Another question.
>> >
>> > Before I saw Linux booting message, there is a line of message:
>> >
>> > (XEN) vgic.c:435:d0 vGICD: GICD_SGIR write r=fe0000 vcpu_mask=fe, wrong 
>> > CPUTargetList
>> >
>> > Is it a big issue for booting dom0?
>>
>> I don't think so. Linux is trying to send an SGI to a non-running VCPU.
>>
>> I'm curious to know why Linux is trying to do this. Can you try to
>> apply the patch below and paste dom0 output log?
>>
>
> FYI,
>
> [    1.139260] CPU: Testing write buffer coherency: ok
> [    1.140167] /cpus/cpu@0 missing clock-frequency property
> [    1.140181] /cpus/cpu@1 missing clock-frequency property
> [    1.140214] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    1.140245] Setting up static identity map for 0xc0511478 - 0xc05114d0
> [    1.143730] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3+ #19
> [    1.143766] [<c001b5ec>] (unwind_backtrace+0x0/0xf8) from [<c0017b90>] 
> (show_stack+0x1)
> [    1.143786] [<c0017b90>] (show_stack+0x10/0x14) from [<c0506940>] 
> (dump_stack+0x70/0x8)
> [    1.143806] [<c0506940>] (dump_stack+0x70/0x8c) from [<c02bca50>] 
> (gic_raise_softirq+0)
> [    1.143823] [<c02bca50>] (gic_raise_softirq+0x64/0x70) from [<c00192f8>] 
> (arch_send_wa)
> [    1.143844] [<c00192f8>] (arch_send_wakeup_ipi_mask+0x18/0x1c) from 
> [<c002e6ec>] (omap)
> [    1.143860] [<c002e6ec>] (omap4_boot_secondary+0xf4/0x174) from 
> [<c0018f78>] (__cpu_up)
> [    1.143877] [<c0018f78>] (__cpu_up+0x84/0x130) from [<c004408c>] 
> (_cpu_up+0xd4/0x154)
> [    1.143894] [<c004408c>] (_cpu_up+0xd4/0x154) from [<c0044184>] 
> (cpu_up+0x5c/0x84)
> [    1.143916] [<c0044184>] (cpu_up+0x5c/0x84) from [<c0740ba4>] 
> (smp_init+0x9c/0xd4)
> [    1.143935] [<c0740ba4>] (smp_init+0x9c/0xd4) from [<c072789c>] 
> (kernel_init_freeable+)
> [    1.143954] [<c072789c>] (kernel_init_freeable+0x70/0x1c4) from 
> [<c0501d2c>] (kernel_i)
> [    1.143972] [<c0501d2c>] (kernel_init+0x8/0xe4) from [<c0013f48>] 
> (ret_from_fork+0x14/)
> [    2.152167] CPU1: failed to come online
> [    2.152516] Brought up 1 CPUs
> [    2.152527] SMP: Total of 1 processors activated (12.28 BogoMIPS).
> [    2.152535] CPU: All CPU(s) started in SVC mode.

Xen uses PSCI to bring up secondary VCPU. It seems Linux is trying to
bring up the CPU with omap callbacks which is wrong.

Did you add a PSCI node in your device tree?
psci {
      compatible      = "arm,psci";
      method          = "hvc";
      cpu_on          = <2>;
};

-- 
Julien Grall

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