Xen project Mailing List

typo

On Thu, Feb 22, 2018 at 4:03 PM, bharat gohil <ghl.bhrt@xxxxxxxxx> wrote:

On Thu, Feb 22, 2018 at 3:15 PM, bharat gohil <ghl.bhrt@xxxxxxxxx> wrote:

On Thu, Feb 22, 2018 at 2:13 PM, bharat gohil <ghl.bhrt@xxxxxxxxx> wrote:

On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
Hello,

On 03/10/17 08:05, bharat gohil wrote:

On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall <julien.grall@xxxxxxx <mailto:julien.grall@xxxxxxx>> wrote:

On 09/29/2017 09:15 AM, bharat gohil wrote:

Hello

Hi,

Please avoid top-posting.

The patch didn't work in my case.

The patch will be useful only if the compatible string in the DT of
your UART is "snps,dw-apb-uart". What is the compatible string for it?

In my case, compatible string is "ns16550a".
Thanks,

Hmmm, looking back at the conversation your dom0 command line is:

console=hvc0,921600n8 earlyprintk=xen debug ignore_loglevel rw root=/dev/mmcblk0p7

earlyprintk=xen will do nothing as there are no Xen specific earlyprintk for Arm. For Dom0, I would recommend to use same same earlyprintk options as you would use on baremetal.

This would allow you to get some early input if the kernel get stuck before the console has been setup.
I have tried your suggestion, I got following crash. It unable find interrupt controller but this kernel working fine without Xen.
Do you have any suggestion?

[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] OF: of_irq_init: children remain, but no parents
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Kernel panic - not syncing: No interrupt controller found.
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.44+ #15
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Hardware name: XXXXX board (DT)
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Call trace:
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008089f88>] dump_backtrace+0x0/0x1d8
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff800808a184>] show_stack+0x24/0x30
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff800838a0e4>] dump_stack+0x94/0xb8
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008196da0>] panic+0x124/0x270
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008c92c08>] init_IRQ+0x24/0x2c
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008c909f8>] start_kernel+0x230/0x388
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008c901e0>] __primary_switched+0x5c/0x64
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Rebooting in 1 seconds..

SoC has different interrupt parent than GIC so I make GIC as interrupt parent and I am able to move ahead. update you once Dom0 boot completely.

System got hang and I got following traces related to energy aware scheduler. Is Xen affected with guest scheduling mechanism? I have SoC which has 4-Cortex A35 and 2-Cortex A72.

System got hang and I got following traces related to energy aware scheduler. Is Xen affected with guest scheduling mechanism? I have SoC which has 4-Cortex A35 and 2-Cortex A72.

[    0.202545] Xen: initializing cpu4
[    0.202562] Invalid sched_group_energy for CPU4
[    0.202564] CPU4: update cpu_capacity 1024
[    0.202566] CPU4: Booted secondary processor [410fd041]
[    0.230197] Detected PIPT I-cache on CPU5
[    0.230202] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR0_EL1. Boot CPU: 0x00000000101122, CPU5: 0x00000000001124
[    0.230250] Xen: initializing cpu5
[    0.230264] Invalid sched_group_energy for CPU5
[    0.230265] CPU5: update cpu_capacity 1024
[    0.230267] CPU5: Booted secondary processor [410fd041]
[    0.230373] Brought up 6 CPUs
[    0.234084] SMP: Total of 6 processors activated.
[    0.234108] CPU features: detected feature: 32-bit EL0 Support
[    0.234382] CPU: All CPU(s) started at EL1
[    0.234627] Invalid sched_group_energy for CPU5
[    0.234662] CPU5: update max cpu_capacity 1024
[    0.234680] Invalid sched_group_energy for Cluster5
[    0.234698] Invalid sched_group_energy for CPU4
[    0.234715] Invalid sched_group_energy for Cluster4
[    0.234733] Invalid sched_group_energy for CPU3
[    0.234750] Invalid sched_group_energy for Cluster3
[    0.234767] Invalid sched_group_energy for CPU2
[    0.234784] Invalid sched_group_energy for Cluster2
[    0.234801] Invalid sched_group_energy for CPU1
[    0.234819] Invalid sched_group_energy for Cluster1
[    0.234836] Invalid sched_group_energy for CPU0
[    0.234853] Invalid

I have SoC with 4 Cortex A35 and 2 Cortex A72.

Furthermore, on a previous e-mail it has been mentioned that your problem might be because Linux will disable what it thinks unused clock. A way to prevent that (at least for debugging) is using add 'clk_ignore_unused' on the Linux command line.

If the 2 suggestions above does not work, then you would have to instrument the kernel. When the hypervisor is build with debug enabled, there are is set a debug hvc provided. A useful one is hvc 0xfffd. For all of them, you can look at do_debug_trap in arch/arm/traps.c.

I hope this will help.

Cheers,

--
Julien Grall

--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@xxxxxxxxxx
+919427054633

--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@xxxxxxxxxx
+919427054633

--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@xxxxxxxxxx
+919427054633

Regards,

Bharat Gohil

Sr.Software Engineer

bharat.gohil@xxxxxxxxxx

+919427054633

Re: [Xen-devel] ARM64:Porting xen to new hardware