* ARM64:Porting xen to new hardware
@ 2017-08-29 14:21 bharat gohil
2017-08-30 14:14 ` Oleksandr Tyshchenko
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-08-29 14:21 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 5726 bytes --]
Hello All
I am trying to run Xen on new hardware which has two A35 and one A72 core.
Xen booted intially but it hangs at *smp_call_function(setup_virt_paging_one,
(void *)val, 1) *function call.
Find following log of Xen booting,
*- UART enabled
- - CPU
00000000 booting - -
Current EL 00000008
- - Xen starting at
EL2 - - Zero BSS
- -
Setting up control registers
- - Turning on paging
- - Ready
-
(XEN) Checking for initrd in
/chosen (XEN) RAM:
0000000040000000 - 00000000bfffffff
(XEN)
(XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device
Tree
(XEN)
(XEN) Command line:
<NULL> (XEN) Placing
Xen at 0x00000000bfe00000-0x00000000c0000000 (XEN)
Update BOOTMOD_XEN from 0000000040080000-0000000040194e01 =>
00000000bfe01(XEN) Domain heap
initialised (XEN) Booting
using Device Tree (XEN)
Platform: Generic System
(XEN) Taking dtuart configuration from
/chosen/stdout-path (XEN) Looking for dtuart at
"serial0", options "" __ __ _
_ _ ___ _ _ _ \ \/ /___ _ __
| || | / |/ _ \ _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \
'_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \
__/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/
/_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
|_|___/\__\__,_|_.__/|_|\___|
(XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
(Ubuntu/Linaro7(XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
git:9053a74-dirty (XEN) Processor: 410fd041: "ARM Limited", variant:
0x0, part 0xd04, rev 0x1 (XEN) 64-bit
Execution: (XEN)
Processor Features: 0000000000002222 0000000000000000
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32
EL0:64+32 (XEN) Extensions: FloatingPoint
AdvancedSIMD (XEN) Debug Features:
0000000010305106 0000000000000000 (XEN) Auxiliary
Features: 0000000000000000 0000000000000000 (XEN)
Memory Model Features: 0000000000101122 0000000000000000
(XEN) ISA Features: 0000000000011120
0000000000000000 (XEN) 32-bit
Execution: (XEN)
Processor Features: 00000131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2
Jazelle (XEN) Extensions: GenericTimer
Security (XEN) Debug Features:
03010066 (XEN) Auxiliary
Features: 00000000 (XEN)
Memory Model Features: 10201105 40000000 01260000 02102211
(XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142
00011121 (XEN) Using PSCI-1.0 for SMP
bringup (XEN) SMP: Allowing 3
CPUs (XEN) Generic
Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz (XEN)
GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000
(XEN) GICv2
initialization:
(XEN)
gic_dist_addr=0000000010510000
(XEN)
gic_cpu_addr=0000000010520000
(XEN)
gic_hyp_addr=0000000010540000
(XEN)
gic_vcpu_addr=0000000010560000
(XEN)
gic_maintenance_irq=25 (XEN)
GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler
(credit) (XEN) Allocated console ring of 32
KiB. (XEN) Bringing up
CPU1 - CPU
00000001 booting - -
Current EL 00000008
- - Xen starting at
EL2 - - Setting up
control registers - -
Turning on paging
- - Ready
-
(XEN) CPU 1
booted. (XEN)
Bringing up CPU2 -
CPU 00000200 booting
- - Current EL
00000008 - - Xen
starting at EL2 - -
Setting up control registers
- - Turning on paging
- - Ready
-
(XEN) CPU 2
booted. (XEN)
Brought up 3 CPUs
(XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit
VMID (XEN) P2M: 3 levels with order-1 root,
VTCR 0x80023558 *
Can anyone guide me how to debug this problem or what could be wrong here?
It looks, writing into VTCR_EL2 hang the system.
--
Regards,
Bharat Gohil
[-- Attachment #1.2: Type: text/html, Size: 10415 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-08-29 14:21 ARM64:Porting xen to new hardware bharat gohil
@ 2017-08-30 14:14 ` Oleksandr Tyshchenko
2017-08-30 14:30 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Oleksandr Tyshchenko @ 2017-08-30 14:14 UTC (permalink / raw)
To: bharat gohil; +Cc: Julien Grall, Stefano Stabellini, Xen Devel
Hi,
Not sure that I am a competent person, just my assumptions.
CCed ARM guys.
On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> Hello All
>
> I am trying to run Xen on new hardware which has two A35 and one A72 core.
> Xen booted intially but it hangs at smp_call_function(setup_virt_paging_one,
> (void *)val, 1) function call.
It might be a consequence of that CPU cores are different. And they
might have different set of features, or even settings.
And these features/settings the boot CPU has don't compatible with
other (non-boot) CPUs.
Can you try not to bringup A72 core (remove it from DT or another
way), leave only two A35 and see what will happen.
> Find following log of Xen booting,same set of features.
>
> - UART enabled -
> - CPU 00000000 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Zero BSS -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) RAM: 0000000040000000 - 00000000bfffffff
> (XEN)
> (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device Tree
> (XEN)
> (XEN) Command line: <NULL>
Why? Does your device-tree have bootargs?
> (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
> (XEN) Update BOOTMOD_XEN from 0000000040080000-0000000040194e01 =>
> 00000000bfe01
> (XEN) Domain heap initialised
> (XEN) Booting using Device Tree
> (XEN) Platform: Generic System
> (XEN) Taking dtuart configuration from /chosen/stdout-path
> (XEN) Looking for dtuart at "serial0", options ""
> __ __ _ _ _ ___ _ _ _
> \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __ _| |__ | | ___
> \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
> / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/
> /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>
> (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
> (Ubuntu/Linaro7
> (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100 git:9053a74-dirty
> (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part 0xd04, rev 0x1
> (XEN) 64-bit Execution:
> (XEN) Processor Features: 0000000000002222 0000000000000000
> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
> (XEN) Extensions: FloatingPoint AdvancedSIMD
> (XEN) Debug Features: 0000000010305106 0000000000000000
> (XEN) Auxiliary Features: 0000000000000000 0000000000000000
> (XEN) Memory Model Features: 0000000000101122 0000000000000000
> (XEN) ISA Features: 0000000000011120 0000000000000000
> (XEN) 32-bit Execution:
> (XEN) Processor Features: 00000131:00011011
> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> (XEN) Extensions: GenericTimer Security
> (XEN) Debug Features: 03010066
> (XEN) Auxiliary Features: 00000000
> (XEN) Memory Model Features: 10201105 40000000 01260000 02102211
> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
> (XEN) Using PSCI-1.0 for SMP bringup
> (XEN) SMP: Allowing 3 CPUs
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
> (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000
Sounds like GIC settings are not completely correct.
Wrong GIC settings might lead to that IPIs won't work as expected. And
boot CPU will
get stuck waiting for another CPU.
Just double check.
> (XEN) GICv2 initialization:
> (XEN) gic_dist_addr=0000000010510000
> (XEN) gic_cpu_addr=0000000010520000
> (XEN) gic_hyp_addr=0000000010540000
> (XEN) gic_vcpu_addr=0000000010560000
> (XEN) gic_maintenance_irq=25
> (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Allocated console ring of 32 KiB.
> (XEN) Bringing up CPU1
> - CPU 00000001 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 1 booted.
> (XEN) Bringing up CPU2
> - CPU 00000200 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 2 booted.
> (XEN) Brought up 3 CPUs
> (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
>
> Can anyone guide me how to debug this problem or what could be wrong here?
>
> It looks, writing into VTCR_EL2 hang the system.
>
> --
> Regards,
> Bharat Gohil
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
>
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-08-30 14:14 ` Oleksandr Tyshchenko
@ 2017-08-30 14:30 ` bharat gohil
2017-08-31 11:13 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-08-30 14:30 UTC (permalink / raw)
To: Oleksandr Tyshchenko; +Cc: Julien Grall, Stefano Stabellini, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 5282 bytes --]
Hello Oleksandr,
Thank you very much for your input.
Yes. agree. I will check by removing A72 core from DT.
Thanks,
Bharat
On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko <olekstysh@gmail.com>
wrote:
> Hi,
>
> Not sure that I am a competent person, just my assumptions.
>
> CCed ARM guys.
>
> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> > Hello All
> >
> > I am trying to run Xen on new hardware which has two A35 and one A72
> core.
> > Xen booted intially but it hangs at smp_call_function(setup_virt_
> paging_one,
> > (void *)val, 1) function call.
>
> It might be a consequence of that CPU cores are different. And they
> might have different set of features, or even settings.
> And these features/settings the boot CPU has don't compatible with
> other (non-boot) CPUs.
> Can you try not to bringup A72 core (remove it from DT or another
> way), leave only two A35 and see what will happen.
>
> > Find following log of Xen booting,same set of features.
> >
> > - UART enabled -
> > - CPU 00000000 booting -
> > - Current EL 00000008 -
> > - Xen starting at EL2 -
> > - Zero BSS -
> > - Setting up control registers -
> > - Turning on paging -
> > - Ready -
> > (XEN) Checking for initrd in /chosen
> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
> > (XEN)
> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device Tree
> > (XEN)
> > (XEN) Command line: <NULL>
> Why? Does your device-tree have bootargs?
>
> > (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
> > (XEN) Update BOOTMOD_XEN from 0000000040080000-0000000040194e01 =>
> > 00000000bfe01
> > (XEN) Domain heap initialised
> > (XEN) Booting using Device Tree
> > (XEN) Platform: Generic System
> > (XEN) Taking dtuart configuration from /chosen/stdout-path
> > (XEN) Looking for dtuart at "serial0", options ""
> > __ __ _ _ _ ___ _ _ _
> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __ _| |__ | |
> ___
> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_ \| |/
> _ \
> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| | |_) | |
> __/
> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
> |_|___/\__\__,_|_.__/|_|\___|
> >
> > (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
> > (Ubuntu/Linaro7
> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100 git:9053a74-dirty
> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part 0xd04, rev
> 0x1
> > (XEN) 64-bit Execution:
> > (XEN) Processor Features: 0000000000002222 0000000000000000
> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
> > (XEN) Extensions: FloatingPoint AdvancedSIMD
> > (XEN) Debug Features: 0000000010305106 0000000000000000
> > (XEN) Auxiliary Features: 0000000000000000 0000000000000000
> > (XEN) Memory Model Features: 0000000000101122 0000000000000000
> > (XEN) ISA Features: 0000000000011120 0000000000000000
> > (XEN) 32-bit Execution:
> > (XEN) Processor Features: 00000131:00011011
> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> > (XEN) Extensions: GenericTimer Security
> > (XEN) Debug Features: 03010066
> > (XEN) Auxiliary Features: 00000000
> > (XEN) Memory Model Features: 10201105 40000000 01260000 02102211
> > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142
> 00011121
> > (XEN) Using PSCI-1.0 for SMP bringup
> > (XEN) SMP: Allowing 3 CPUs
> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000
> Sounds like GIC settings are not completely correct.
> Wrong GIC settings might lead to that IPIs won't work as expected. And
> boot CPU will
> get stuck waiting for another CPU.
> Just double check.
>
> > (XEN) GICv2 initialization:
> > (XEN) gic_dist_addr=0000000010510000
> > (XEN) gic_cpu_addr=0000000010520000
> > (XEN) gic_hyp_addr=0000000010540000
> > (XEN) gic_vcpu_addr=0000000010560000
> > (XEN) gic_maintenance_irq=25
> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > (XEN) Allocated console ring of 32 KiB.
> > (XEN) Bringing up CPU1
> > - CPU 00000001 booting -
> > - Current EL 00000008 -
> > - Xen starting at EL2 -
> > - Setting up control registers -
> > - Turning on paging -
> > - Ready -
> > (XEN) CPU 1 booted.
> > (XEN) Bringing up CPU2
> > - CPU 00000200 booting -
> > - Current EL 00000008 -
> > - Xen starting at EL2 -
> > - Setting up control registers -
> > - Turning on paging -
> > - Ready -
> > (XEN) CPU 2 booted.
> > (XEN) Brought up 3 CPUs
> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> >
> > Can anyone guide me how to debug this problem or what could be wrong
> here?
> >
> > It looks, writing into VTCR_EL2 hang the system.
> >
> > --
> > Regards,
> > Bharat Gohil
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
> >
>
> --
> Regards,
>
> Oleksandr Tyshchenko
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 7168 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-08-30 14:30 ` bharat gohil
@ 2017-08-31 11:13 ` bharat gohil
2017-08-31 11:58 ` Oleksandr Tyshchenko
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-08-31 11:13 UTC (permalink / raw)
To: Oleksandr Tyshchenko; +Cc: Julien Grall, Stefano Stabellini, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 5811 bytes --]
Hello Oleksandr,
I had removed A72 cluster and tried to boot only two A35 but I got same
error.
Is anything added or missing in A35 compare to A53?
Regards,
Bharat
On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> Hello Oleksandr,
> Thank you very much for your input.
>
> Yes. agree. I will check by removing A72 core from DT.
>
> Thanks,
> Bharat
>
> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko <olekstysh@gmail.com
> > wrote:
>
>> Hi,
>>
>> Not sure that I am a competent person, just my assumptions.
>>
>> CCed ARM guys.
>>
>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>> > Hello All
>> >
>> > I am trying to run Xen on new hardware which has two A35 and one A72
>> core.
>> > Xen booted intially but it hangs at smp_call_function(setup_virt_p
>> aging_one,
>> > (void *)val, 1) function call.
>>
>> It might be a consequence of that CPU cores are different. And they
>> might have different set of features, or even settings.
>> And these features/settings the boot CPU has don't compatible with
>> other (non-boot) CPUs.
>> Can you try not to bringup A72 core (remove it from DT or another
>> way), leave only two A35 and see what will happen.
>>
>> > Find following log of Xen booting,same set of features.
>> >
>> > - UART enabled -
>> > - CPU 00000000 booting -
>> > - Current EL 00000008 -
>> > - Xen starting at EL2 -
>> > - Zero BSS -
>> > - Setting up control registers -
>> > - Turning on paging -
>> > - Ready -
>> > (XEN) Checking for initrd in /chosen
>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
>> > (XEN)
>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device Tree
>> > (XEN)
>> > (XEN) Command line: <NULL>
>> Why? Does your device-tree have bootargs?
>>
>> > (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
>> > (XEN) Update BOOTMOD_XEN from 0000000040080000-0000000040194e01 =>
>> > 00000000bfe01
>> > (XEN) Domain heap initialised
>> > (XEN) Booting using Device Tree
>> > (XEN) Platform: Generic System
>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
>> > (XEN) Looking for dtuart at "serial0", options ""
>> > __ __ _ _ _ ___ _ _ _
>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __ _| |__ | |
>> ___
>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_ \|
>> |/ _ \
>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| | |_) |
>> | __/
>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
>> |_|___/\__\__,_|_.__/|_|\___|
>> >
>> > (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
>> > (Ubuntu/Linaro7
>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100 git:9053a74-dirty
>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part 0xd04, rev
>> 0x1
>> > (XEN) 64-bit Execution:
>> > (XEN) Processor Features: 0000000000002222 0000000000000000
>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
>> > (XEN) Debug Features: 0000000010305106 0000000000000000
>> > (XEN) Auxiliary Features: 0000000000000000 0000000000000000
>> > (XEN) Memory Model Features: 0000000000101122 0000000000000000
>> > (XEN) ISA Features: 0000000000011120 0000000000000000
>> > (XEN) 32-bit Execution:
>> > (XEN) Processor Features: 00000131:00011011
>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
>> > (XEN) Extensions: GenericTimer Security
>> > (XEN) Debug Features: 03010066
>> > (XEN) Auxiliary Features: 00000000
>> > (XEN) Memory Model Features: 10201105 40000000 01260000 02102211
>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142
>> 00011121
>> > (XEN) Using PSCI-1.0 for SMP bringup
>> > (XEN) SMP: Allowing 3 CPUs
>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000
>> Sounds like GIC settings are not completely correct.
>> Wrong GIC settings might lead to that IPIs won't work as expected. And
>> boot CPU will
>> get stuck waiting for another CPU.
>> Just double check.
>>
>> > (XEN) GICv2 initialization:
>> > (XEN) gic_dist_addr=0000000010510000
>> > (XEN) gic_cpu_addr=0000000010520000
>> > (XEN) gic_hyp_addr=0000000010540000
>> > (XEN) gic_vcpu_addr=0000000010560000
>> > (XEN) gic_maintenance_irq=25
>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> > (XEN) Allocated console ring of 32 KiB.
>> > (XEN) Bringing up CPU1
>> > - CPU 00000001 booting -
>> > - Current EL 00000008 -
>> > - Xen starting at EL2 -
>> > - Setting up control registers -
>> > - Turning on paging -
>> > - Ready -
>> > (XEN) CPU 1 booted.
>> > (XEN) Bringing up CPU2
>> > - CPU 00000200 booting -
>> > - Current EL 00000008 -
>> > - Xen starting at EL2 -
>> > - Setting up control registers -
>> > - Turning on paging -
>> > - Ready -
>> > (XEN) CPU 2 booted.
>> > (XEN) Brought up 3 CPUs
>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
>> >
>> > Can anyone guide me how to debug this problem or what could be wrong
>> here?
>> >
>> > It looks, writing into VTCR_EL2 hang the system.
>> >
>> > --
>> > Regards,
>> > Bharat Gohil
>> >
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > https://lists.xen.org/xen-devel
>> >
>>
>> --
>> Regards,
>>
>> Oleksandr Tyshchenko
>>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com
> +919427054633 <+91%2094270%2054633>
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 8402 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-08-31 11:13 ` bharat gohil
@ 2017-08-31 11:58 ` Oleksandr Tyshchenko
2017-09-04 4:13 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Oleksandr Tyshchenko @ 2017-08-31 11:58 UTC (permalink / raw)
To: bharat gohil; +Cc: Julien Grall, Stefano Stabellini, Xen Devel
On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> Hello Oleksandr,
Hi Bharat
>
> I had removed A72 cluster and tried to boot only two A35 but I got same
> error.
>
> Is anything added or missing in A35 compare to A53?
Unfortunately, I don't know.
BTW, did you check your GIC settings in the device-tree?
>
> Regards,
> Bharat
>
> On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>>
>> Hello Oleksandr,
>> Thank you very much for your input.
>>
>> Yes. agree. I will check by removing A72 core from DT.
>>
>> Thanks,
>> Bharat
>>
>> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
>> <olekstysh@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Not sure that I am a competent person, just my assumptions.
>>>
>>> CCed ARM guys.
>>>
>>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>>> > Hello All
>>> >
>>> > I am trying to run Xen on new hardware which has two A35 and one A72
>>> > core.
>>> > Xen booted intially but it hangs at
>>> > smp_call_function(setup_virt_paging_one,
>>> > (void *)val, 1) function call.
>>>
>>> It might be a consequence of that CPU cores are different. And they
>>> might have different set of features, or even settings.
>>> And these features/settings the boot CPU has don't compatible with
>>> other (non-boot) CPUs.
>>> Can you try not to bringup A72 core (remove it from DT or another
>>> way), leave only two A35 and see what will happen.
>>>
>>> > Find following log of Xen booting,same set of features.
>>> >
>>> > - UART enabled -
>>> > - CPU 00000000 booting -
>>> > - Current EL 00000008 -
>>> > - Xen starting at EL2 -
>>> > - Zero BSS -
>>> > - Setting up control registers -
>>> > - Turning on paging -
>>> > - Ready -
>>> > (XEN) Checking for initrd in /chosen
>>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
>>> > (XEN)
>>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device Tree
>>> > (XEN)
>>> > (XEN) Command line: <NULL>
>>> Why? Does your device-tree have bootargs?
>>>
>>> > (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
>>> > (XEN) Update BOOTMOD_XEN from 0000000040080000-0000000040194e01 =>
>>> > 00000000bfe01
>>> > (XEN) Domain heap initialised
>>> > (XEN) Booting using Device Tree
>>> > (XEN) Platform: Generic System
>>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
>>> > (XEN) Looking for dtuart at "serial0", options ""
>>> > __ __ _ _ _ ___ _ _ _
>>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __ _| |__ | |
>>> > ___
>>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_ \|
>>> > |/ _ \
>>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| | |_) | |
>>> > __/
>>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
>>> > |_|___/\__\__,_|_.__/|_|\___|
>>> >
>>> > (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
>>> > (Ubuntu/Linaro7
>>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
>>> > git:9053a74-dirty
>>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part 0xd04, rev
>>> > 0x1
>>> > (XEN) 64-bit Execution:
>>> > (XEN) Processor Features: 0000000000002222 0000000000000000
>>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
>>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
>>> > (XEN) Debug Features: 0000000010305106 0000000000000000
>>> > (XEN) Auxiliary Features: 0000000000000000 0000000000000000
>>> > (XEN) Memory Model Features: 0000000000101122 0000000000000000
>>> > (XEN) ISA Features: 0000000000011120 0000000000000000
>>> > (XEN) 32-bit Execution:
>>> > (XEN) Processor Features: 00000131:00011011
>>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
>>> > (XEN) Extensions: GenericTimer Security
>>> > (XEN) Debug Features: 03010066
>>> > (XEN) Auxiliary Features: 00000000
>>> > (XEN) Memory Model Features: 10201105 40000000 01260000 02102211
>>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142
>>> > 00011121
>>> > (XEN) Using PSCI-1.0 for SMP bringup
>>> > (XEN) SMP: Allowing 3 CPUs
>>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
>>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
>>> > 0x2000
>>> Sounds like GIC settings are not completely correct.
>>> Wrong GIC settings might lead to that IPIs won't work as expected. And
>>> boot CPU will
>>> get stuck waiting for another CPU.
>>> Just double check.
>>>
>>> > (XEN) GICv2 initialization:
>>> > (XEN) gic_dist_addr=0000000010510000
>>> > (XEN) gic_cpu_addr=0000000010520000
>>> > (XEN) gic_hyp_addr=0000000010540000
>>> > (XEN) gic_vcpu_addr=0000000010560000
>>> > (XEN) gic_maintenance_irq=25
>>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
>>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
>>> > (XEN) Allocated console ring of 32 KiB.
>>> > (XEN) Bringing up CPU1
>>> > - CPU 00000001 booting -
>>> > - Current EL 00000008 -
>>> > - Xen starting at EL2 -
>>> > - Setting up control registers -
>>> > - Turning on paging -
>>> > - Ready -
>>> > (XEN) CPU 1 booted.
>>> > (XEN) Bringing up CPU2
>>> > - CPU 00000200 booting -
>>> > - Current EL 00000008 -
>>> > - Xen starting at EL2 -
>>> > - Setting up control registers -
>>> > - Turning on paging -
>>> > - Ready -
>>> > (XEN) CPU 2 booted.
>>> > (XEN) Brought up 3 CPUs
>>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
>>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
>>> >
>>> > Can anyone guide me how to debug this problem or what could be wrong
>>> > here?
>>> >
>>> > It looks, writing into VTCR_EL2 hang the system.
>>> >
>>> > --
>>> > Regards,
>>> > Bharat Gohil
>>> >
>>> >
>>> > _______________________________________________
>>> > Xen-devel mailing list
>>> > Xen-devel@lists.xen.org
>>> > https://lists.xen.org/xen-devel
>>> >
>>>
>>> --
>>> Regards,
>>>
>>> Oleksandr Tyshchenko
>>
>>
>>
>>
>> --
>> Regards,
>> Bharat Gohil
>> Sr.Software Engineer
>> bharat.gohil@harman.com
>> +919427054633
>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com
> +919427054633
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-08-31 11:58 ` Oleksandr Tyshchenko
@ 2017-09-04 4:13 ` bharat gohil
2017-09-04 12:54 ` Oleksandr Tyshchenko
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-09-04 4:13 UTC (permalink / raw)
To: Oleksandr Tyshchenko; +Cc: Julien Grall, Stefano Stabellini, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 7528 bytes --]
Hello Oleksandr,
I have corrected GIC settings but no success.Following line disappear from
log.
*>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
0x2000 *
Is anything else which can I try.
I don’t know much about xen internal for ARM architecture. As you mentioned,
>>Wrong GIC settings might lead to that IPIs won't work as expected. And
>>boot CPU will get stuck waiting for another CPU.
Can you explain it with some boot sequence and relation with IPI?
Thanks,
Bharat
On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko <olekstysh@gmail.com>
wrote:
> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> > Hello Oleksandr,
> Hi Bharat
>
> >
> > I had removed A72 cluster and tried to boot only two A35 but I got same
> > error.
> >
> > Is anything added or missing in A35 compare to A53?
> Unfortunately, I don't know.
>
> BTW, did you check your GIC settings in the device-tree?
>
> >
> > Regards,
> > Bharat
> >
> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <ghl.bhrt@gmail.com>
> wrote:
> >>
> >> Hello Oleksandr,
> >> Thank you very much for your input.
> >>
> >> Yes. agree. I will check by removing A72 core from DT.
> >>
> >> Thanks,
> >> Bharat
> >>
> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
> >> <olekstysh@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Not sure that I am a competent person, just my assumptions.
> >>>
> >>> CCed ARM guys.
> >>>
> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil <ghl.bhrt@gmail.com>
> wrote:
> >>> > Hello All
> >>> >
> >>> > I am trying to run Xen on new hardware which has two A35 and one A72
> >>> > core.
> >>> > Xen booted intially but it hangs at
> >>> > smp_call_function(setup_virt_paging_one,
> >>> > (void *)val, 1) function call.
> >>>
> >>> It might be a consequence of that CPU cores are different. And they
> >>> might have different set of features, or even settings.
> >>> And these features/settings the boot CPU has don't compatible with
> >>> other (non-boot) CPUs.
> >>> Can you try not to bringup A72 core (remove it from DT or another
> >>> way), leave only two A35 and see what will happen.
> >>>
> >>> > Find following log of Xen booting,same set of features.
> >>> >
> >>> > - UART enabled -
> >>> > - CPU 00000000 booting -
> >>> > - Current EL 00000008 -
> >>> > - Xen starting at EL2 -
> >>> > - Zero BSS -
> >>> > - Setting up control registers -
> >>> > - Turning on paging -
> >>> > - Ready -
> >>> > (XEN) Checking for initrd in /chosen
> >>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
> >>> > (XEN)
> >>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device Tree
> >>> > (XEN)
> >>> > (XEN) Command line: <NULL>
> >>> Why? Does your device-tree have bootargs?
> >>>
> >>> > (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
> >>> > (XEN) Update BOOTMOD_XEN from 0000000040080000-0000000040194e01 =>
> >>> > 00000000bfe01
> >>> > (XEN) Domain heap initialised
> >>> > (XEN) Booting using Device Tree
> >>> > (XEN) Platform: Generic System
> >>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
> >>> > (XEN) Looking for dtuart at "serial0", options ""
> >>> > __ __ _ _ _ ___ _ _
> _
> >>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __ _| |__
> | |
> >>> > ___
> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_ \|
> >>> > |/ _ \
> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| | |_)
> | |
> >>> > __/
> >>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
> >>> > |_|___/\__\__,_|_.__/|_|\___|
> >>> >
> >>> > (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
> >>> > (Ubuntu/Linaro7
> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
> >>> > git:9053a74-dirty
> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part 0xd04,
> rev
> >>> > 0x1
> >>> > (XEN) 64-bit Execution:
> >>> > (XEN) Processor Features: 0000000000002222 0000000000000000
> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
> >>> > (XEN) Debug Features: 0000000010305106 0000000000000000
> >>> > (XEN) Auxiliary Features: 0000000000000000 0000000000000000
> >>> > (XEN) Memory Model Features: 0000000000101122 0000000000000000
> >>> > (XEN) ISA Features: 0000000000011120 0000000000000000
> >>> > (XEN) 32-bit Execution:
> >>> > (XEN) Processor Features: 00000131:00011011
> >>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> >>> > (XEN) Extensions: GenericTimer Security
> >>> > (XEN) Debug Features: 03010066
> >>> > (XEN) Auxiliary Features: 00000000
> >>> > (XEN) Memory Model Features: 10201105 40000000 01260000 02102211
> >>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142
> >>> > 00011121
> >>> > (XEN) Using PSCI-1.0 for SMP bringup
> >>> > (XEN) SMP: Allowing 3 CPUs
> >>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
> >>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
> >>> > 0x2000
> >>> Sounds like GIC settings are not completely correct.
> >>> Wrong GIC settings might lead to that IPIs won't work as expected. And
> >>> boot CPU will
> >>> get stuck waiting for another CPU.
> >>> Just double check.
> >>>
> >>> > (XEN) GICv2 initialization:
> >>> > (XEN) gic_dist_addr=0000000010510000
> >>> > (XEN) gic_cpu_addr=0000000010520000
> >>> > (XEN) gic_hyp_addr=0000000010540000
> >>> > (XEN) gic_vcpu_addr=0000000010560000
> >>> > (XEN) gic_maintenance_irq=25
> >>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
> >>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >>> > (XEN) Allocated console ring of 32 KiB.
> >>> > (XEN) Bringing up CPU1
> >>> > - CPU 00000001 booting -
> >>> > - Current EL 00000008 -
> >>> > - Xen starting at EL2 -
> >>> > - Setting up control registers -
> >>> > - Turning on paging -
> >>> > - Ready -
> >>> > (XEN) CPU 1 booted.
> >>> > (XEN) Bringing up CPU2
> >>> > - CPU 00000200 booting -
> >>> > - Current EL 00000008 -
> >>> > - Xen starting at EL2 -
> >>> > - Setting up control registers -
> >>> > - Turning on paging -
> >>> > - Ready -
> >>> > (XEN) CPU 2 booted.
> >>> > (XEN) Brought up 3 CPUs
> >>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> >>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> >>> >
> >>> > Can anyone guide me how to debug this problem or what could be wrong
> >>> > here?
> >>> >
> >>> > It looks, writing into VTCR_EL2 hang the system.
> >>> >
> >>> > --
> >>> > Regards,
> >>> > Bharat Gohil
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > Xen-devel mailing list
> >>> > Xen-devel@lists.xen.org
> >>> > https://lists.xen.org/xen-devel
> >>> >
> >>>
> >>> --
> >>> Regards,
> >>>
> >>> Oleksandr Tyshchenko
> >>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Bharat Gohil
> >> Sr.Software Engineer
> >> bharat.gohil@harman.com
> >> +919427054633
> >
> >
> >
> >
> > --
> > Regards,
> > Bharat Gohil
> > Sr.Software Engineer
> > bharat.gohil@harman.com
> > +919427054633
>
>
>
> --
> Regards,
>
> Oleksandr Tyshchenko
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 11238 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-04 4:13 ` bharat gohil
@ 2017-09-04 12:54 ` Oleksandr Tyshchenko
2017-09-06 7:01 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Oleksandr Tyshchenko @ 2017-09-04 12:54 UTC (permalink / raw)
To: bharat gohil; +Cc: Julien Grall, Stefano Stabellini, Xen Devel
Hi Bharat
On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> Hello Oleksandr,
>
> I have corrected GIC settings but no success.Following line disappear from
> log.
>>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000
>
> Is anything else which can I try.
>
> I don’t know much about xen internal for ARM architecture. As you mentioned,
>>>Wrong GIC settings might lead to that IPIs won't work as expected. And
>>>boot CPU will get stuck waiting for another CPU.
>
> Can you explain it with some boot sequence and relation with IPI?
Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at
smp_call_function (one CPU didn't receive interrupt from another one).
Next patch helped us to fix this issue:
https://patchwork.kernel.org/patch/9163065/
I assume the SoC you are working with has "arm,gic-400" compatible GIC.
Can you take a look at the patch, maybe it is your case too.
>
> Thanks,
> Bharat
>
>
> On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko <olekstysh@gmail.com>
> wrote:
>>
>> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>> > Hello Oleksandr,
>> Hi Bharat
>>
>> >
>> > I had removed A72 cluster and tried to boot only two A35 but I got same
>> > error.
>> >
>> > Is anything added or missing in A35 compare to A53?
>> Unfortunately, I don't know.
>>
>> BTW, did you check your GIC settings in the device-tree?
>>
>> >
>> > Regards,
>> > Bharat
>> >
>> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <ghl.bhrt@gmail.com>
>> > wrote:
>> >>
>> >> Hello Oleksandr,
>> >> Thank you very much for your input.
>> >>
>> >> Yes. agree. I will check by removing A72 core from DT.
>> >>
>> >> Thanks,
>> >> Bharat
>> >>
>> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
>> >> <olekstysh@gmail.com> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Not sure that I am a competent person, just my assumptions.
>> >>>
>> >>> CCed ARM guys.
>> >>>
>> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil <ghl.bhrt@gmail.com>
>> >>> wrote:
>> >>> > Hello All
>> >>> >
>> >>> > I am trying to run Xen on new hardware which has two A35 and one A72
>> >>> > core.
>> >>> > Xen booted intially but it hangs at
>> >>> > smp_call_function(setup_virt_paging_one,
>> >>> > (void *)val, 1) function call.
>> >>>
>> >>> It might be a consequence of that CPU cores are different. And they
>> >>> might have different set of features, or even settings.
>> >>> And these features/settings the boot CPU has don't compatible with
>> >>> other (non-boot) CPUs.
>> >>> Can you try not to bringup A72 core (remove it from DT or another
>> >>> way), leave only two A35 and see what will happen.
>> >>>
>> >>> > Find following log of Xen booting,same set of features.
>> >>> >
>> >>> > - UART enabled -
>> >>> > - CPU 00000000 booting -
>> >>> > - Current EL 00000008 -
>> >>> > - Xen starting at EL2 -
>> >>> > - Zero BSS -
>> >>> > - Setting up control registers -
>> >>> > - Turning on paging -
>> >>> > - Ready -
>> >>> > (XEN) Checking for initrd in /chosen
>> >>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
>> >>> > (XEN)
>> >>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device Tree
>> >>> > (XEN)
>> >>> > (XEN) Command line: <NULL>
>> >>> Why? Does your device-tree have bootargs?
>> >>>
>> >>> > (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
>> >>> > (XEN) Update BOOTMOD_XEN from 0000000040080000-0000000040194e01 =>
>> >>> > 00000000bfe01
>> >>> > (XEN) Domain heap initialised
>> >>> > (XEN) Booting using Device Tree
>> >>> > (XEN) Platform: Generic System
>> >>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
>> >>> > (XEN) Looking for dtuart at "serial0", options ""
>> >>> > __ __ _ _ _ ___ _ _
>> >>> > _
>> >>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __ _| |__
>> >>> > | |
>> >>> > ___
>> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_
>> >>> > \|
>> >>> > |/ _ \
>> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| | |_)
>> >>> > | |
>> >>> > __/
>> >>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
>> >>> > |_|___/\__\__,_|_.__/|_|\___|
>> >>> >
>> >>> > (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
>> >>> > (Ubuntu/Linaro7
>> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
>> >>> > git:9053a74-dirty
>> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part 0xd04,
>> >>> > rev
>> >>> > 0x1
>> >>> > (XEN) 64-bit Execution:
>> >>> > (XEN) Processor Features: 0000000000002222 0000000000000000
>> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
>> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
>> >>> > (XEN) Debug Features: 0000000010305106 0000000000000000
>> >>> > (XEN) Auxiliary Features: 0000000000000000 0000000000000000
>> >>> > (XEN) Memory Model Features: 0000000000101122 0000000000000000
>> >>> > (XEN) ISA Features: 0000000000011120 0000000000000000
>> >>> > (XEN) 32-bit Execution:
>> >>> > (XEN) Processor Features: 00000131:00011011
>> >>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
>> >>> > (XEN) Extensions: GenericTimer Security
>> >>> > (XEN) Debug Features: 03010066
>> >>> > (XEN) Auxiliary Features: 00000000
>> >>> > (XEN) Memory Model Features: 10201105 40000000 01260000 02102211
>> >>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142
>> >>> > 00011121
>> >>> > (XEN) Using PSCI-1.0 for SMP bringup
>> >>> > (XEN) SMP: Allowing 3 CPUs
>> >>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
>> >>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
>> >>> > 0x2000
>> >>> Sounds like GIC settings are not completely correct.
>> >>> Wrong GIC settings might lead to that IPIs won't work as expected. And
>> >>> boot CPU will
>> >>> get stuck waiting for another CPU.
>> >>> Just double check.
>> >>>
>> >>> > (XEN) GICv2 initialization:
>> >>> > (XEN) gic_dist_addr=0000000010510000
>> >>> > (XEN) gic_cpu_addr=0000000010520000
>> >>> > (XEN) gic_hyp_addr=0000000010540000
>> >>> > (XEN) gic_vcpu_addr=0000000010560000
>> >>> > (XEN) gic_maintenance_irq=25
>> >>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
>> >>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> >>> > (XEN) Allocated console ring of 32 KiB.
>> >>> > (XEN) Bringing up CPU1
>> >>> > - CPU 00000001 booting -
>> >>> > - Current EL 00000008 -
>> >>> > - Xen starting at EL2 -
>> >>> > - Setting up control registers -
>> >>> > - Turning on paging -
>> >>> > - Ready -
>> >>> > (XEN) CPU 1 booted.
>> >>> > (XEN) Bringing up CPU2
>> >>> > - CPU 00000200 booting -
>> >>> > - Current EL 00000008 -
>> >>> > - Xen starting at EL2 -
>> >>> > - Setting up control registers -
>> >>> > - Turning on paging -
>> >>> > - Ready -
>> >>> > (XEN) CPU 2 booted.
>> >>> > (XEN) Brought up 3 CPUs
>> >>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
>> >>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
>> >>> >
>> >>> > Can anyone guide me how to debug this problem or what could be wrong
>> >>> > here?
>> >>> >
>> >>> > It looks, writing into VTCR_EL2 hang the system.
>> >>> >
>> >>> > --
>> >>> > Regards,
>> >>> > Bharat Gohil
>> >>> >
>> >>> >
>> >>> > _______________________________________________
>> >>> > Xen-devel mailing list
>> >>> > Xen-devel@lists.xen.org
>> >>> > https://lists.xen.org/xen-devel
>> >>> >
>> >>>
>> >>> --
>> >>> Regards,
>> >>>
>> >>> Oleksandr Tyshchenko
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Bharat Gohil
>> >> Sr.Software Engineer
>> >> bharat.gohil@harman.com
>> >> +919427054633
>> >
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Bharat Gohil
>> > Sr.Software Engineer
>> > bharat.gohil@harman.com
>> > +919427054633
>>
>>
>>
>> --
>> Regards,
>>
>> Oleksandr Tyshchenko
>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com
> +919427054633
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-04 12:54 ` Oleksandr Tyshchenko
@ 2017-09-06 7:01 ` bharat gohil
2017-09-06 10:19 ` Oleksandr Tyshchenko
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-09-06 7:01 UTC (permalink / raw)
To: Oleksandr Tyshchenko; +Cc: Julien Grall, Stefano Stabellini, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 9121 bytes --]
Hello Oleksandr,
Thank you very much.It resolved my issue.
Thanks,
Bharat
On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko <olekstysh@gmail.com>
wrote:
> Hi Bharat
>
> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> > Hello Oleksandr,
> >
> > I have corrected GIC settings but no success.Following line disappear
> from
> > log.
> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000
> >
> > Is anything else which can I try.
> >
> > I don’t know much about xen internal for ARM architecture. As you
> mentioned,
> >>>Wrong GIC settings might lead to that IPIs won't work as expected. And
> >>>boot CPU will get stuck waiting for another CPU.
> >
> > Can you explain it with some boot sequence and relation with IPI?
>
> Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at
> smp_call_function (one CPU didn't receive interrupt from another one).
> Next patch helped us to fix this issue:
> https://patchwork.kernel.org/patch/9163065/
>
> I assume the SoC you are working with has "arm,gic-400" compatible GIC.
> Can you take a look at the patch, maybe it is your case too.
>
> >
> > Thanks,
> > Bharat
> >
> >
> > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko <
> olekstysh@gmail.com>
> > wrote:
> >>
> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com>
> wrote:
> >> > Hello Oleksandr,
> >> Hi Bharat
> >>
> >> >
> >> > I had removed A72 cluster and tried to boot only two A35 but I got
> same
> >> > error.
> >> >
> >> > Is anything added or missing in A35 compare to A53?
> >> Unfortunately, I don't know.
> >>
> >> BTW, did you check your GIC settings in the device-tree?
> >>
> >> >
> >> > Regards,
> >> > Bharat
> >> >
> >> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <ghl.bhrt@gmail.com>
> >> > wrote:
> >> >>
> >> >> Hello Oleksandr,
> >> >> Thank you very much for your input.
> >> >>
> >> >> Yes. agree. I will check by removing A72 core from DT.
> >> >>
> >> >> Thanks,
> >> >> Bharat
> >> >>
> >> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
> >> >> <olekstysh@gmail.com> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> Not sure that I am a competent person, just my assumptions.
> >> >>>
> >> >>> CCed ARM guys.
> >> >>>
> >> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil <ghl.bhrt@gmail.com>
> >> >>> wrote:
> >> >>> > Hello All
> >> >>> >
> >> >>> > I am trying to run Xen on new hardware which has two A35 and one
> A72
> >> >>> > core.
> >> >>> > Xen booted intially but it hangs at
> >> >>> > smp_call_function(setup_virt_paging_one,
> >> >>> > (void *)val, 1) function call.
> >> >>>
> >> >>> It might be a consequence of that CPU cores are different. And they
> >> >>> might have different set of features, or even settings.
> >> >>> And these features/settings the boot CPU has don't compatible with
> >> >>> other (non-boot) CPUs.
> >> >>> Can you try not to bringup A72 core (remove it from DT or another
> >> >>> way), leave only two A35 and see what will happen.
> >> >>>
> >> >>> > Find following log of Xen booting,same set of features.
> >> >>> >
> >> >>> > - UART enabled -
> >> >>> > - CPU 00000000 booting -
> >> >>> > - Current EL 00000008 -
> >> >>> > - Xen starting at EL2 -
> >> >>> > - Zero BSS -
> >> >>> > - Setting up control registers -
> >> >>> > - Turning on paging -
> >> >>> > - Ready -
> >> >>> > (XEN) Checking for initrd in /chosen
> >> >>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
> >> >>> > (XEN)
> >> >>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device Tree
> >> >>> > (XEN)
> >> >>> > (XEN) Command line: <NULL>
> >> >>> Why? Does your device-tree have bootargs?
> >> >>>
> >> >>> > (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
> >> >>> > (XEN) Update BOOTMOD_XEN from 0000000040080000-0000000040194e01
> =>
> >> >>> > 00000000bfe01
> >> >>> > (XEN) Domain heap initialised
> >> >>> > (XEN) Booting using Device Tree
> >> >>> > (XEN) Platform: Generic System
> >> >>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
> >> >>> > (XEN) Looking for dtuart at "serial0", options ""
> >> >>> > __ __ _ _ _ ___ _ _
> >> >>> > _
> >> >>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __ _|
> |__
> >> >>> > | |
> >> >>> > ___
> >> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_
> >> >>> > \|
> >> >>> > |/ _ \
> >> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| |
> |_)
> >> >>> > | |
> >> >>> > __/
> >> >>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
> >> >>> > |_|___/\__\__,_|_.__/|_|\___|
> >> >>> >
> >> >>> > (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
> >> >>> > (Ubuntu/Linaro7
> >> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
> >> >>> > git:9053a74-dirty
> >> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part
> 0xd04,
> >> >>> > rev
> >> >>> > 0x1
> >> >>> > (XEN) 64-bit Execution:
> >> >>> > (XEN) Processor Features: 0000000000002222 0000000000000000
> >> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32
> EL0:64+32
> >> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
> >> >>> > (XEN) Debug Features: 0000000010305106 0000000000000000
> >> >>> > (XEN) Auxiliary Features: 0000000000000000 0000000000000000
> >> >>> > (XEN) Memory Model Features: 0000000000101122 0000000000000000
> >> >>> > (XEN) ISA Features: 0000000000011120 0000000000000000
> >> >>> > (XEN) 32-bit Execution:
> >> >>> > (XEN) Processor Features: 00000131:00011011
> >> >>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> >> >>> > (XEN) Extensions: GenericTimer Security
> >> >>> > (XEN) Debug Features: 03010066
> >> >>> > (XEN) Auxiliary Features: 00000000
> >> >>> > (XEN) Memory Model Features: 10201105 40000000 01260000 02102211
> >> >>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142
> >> >>> > 00011121
> >> >>> > (XEN) Using PSCI-1.0 for SMP bringup
> >> >>> > (XEN) SMP: Allowing 3 CPUs
> >> >>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
> >> >>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
> >> >>> > 0x2000
> >> >>> Sounds like GIC settings are not completely correct.
> >> >>> Wrong GIC settings might lead to that IPIs won't work as expected.
> And
> >> >>> boot CPU will
> >> >>> get stuck waiting for another CPU.
> >> >>> Just double check.
> >> >>>
> >> >>> > (XEN) GICv2 initialization:
> >> >>> > (XEN) gic_dist_addr=0000000010510000
> >> >>> > (XEN) gic_cpu_addr=0000000010520000
> >> >>> > (XEN) gic_hyp_addr=0000000010540000
> >> >>> > (XEN) gic_vcpu_addr=0000000010560000
> >> >>> > (XEN) gic_maintenance_irq=25
> >> >>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
> >> >>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >> >>> > (XEN) Allocated console ring of 32 KiB.
> >> >>> > (XEN) Bringing up CPU1
> >> >>> > - CPU 00000001 booting -
> >> >>> > - Current EL 00000008 -
> >> >>> > - Xen starting at EL2 -
> >> >>> > - Setting up control registers -
> >> >>> > - Turning on paging -
> >> >>> > - Ready -
> >> >>> > (XEN) CPU 1 booted.
> >> >>> > (XEN) Bringing up CPU2
> >> >>> > - CPU 00000200 booting -
> >> >>> > - Current EL 00000008 -
> >> >>> > - Xen starting at EL2 -
> >> >>> > - Setting up control registers -
> >> >>> > - Turning on paging -
> >> >>> > - Ready -
> >> >>> > (XEN) CPU 2 booted.
> >> >>> > (XEN) Brought up 3 CPUs
> >> >>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> >> >>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> >> >>> >
> >> >>> > Can anyone guide me how to debug this problem or what could be
> wrong
> >> >>> > here?
> >> >>> >
> >> >>> > It looks, writing into VTCR_EL2 hang the system.
> >> >>> >
> >> >>> > --
> >> >>> > Regards,
> >> >>> > Bharat Gohil
> >> >>> >
> >> >>> >
> >> >>> > _______________________________________________
> >> >>> > Xen-devel mailing list
> >> >>> > Xen-devel@lists.xen.org
> >> >>> > https://lists.xen.org/xen-devel
> >> >>> >
> >> >>>
> >> >>> --
> >> >>> Regards,
> >> >>>
> >> >>> Oleksandr Tyshchenko
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Regards,
> >> >> Bharat Gohil
> >> >> Sr.Software Engineer
> >> >> bharat.gohil@harman.com
> >> >> +919427054633
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Bharat Gohil
> >> > Sr.Software Engineer
> >> > bharat.gohil@harman.com
> >> > +919427054633
> >>
> >>
> >>
> >> --
> >> Regards,
> >>
> >> Oleksandr Tyshchenko
> >
> >
> >
> >
> > --
> > Regards,
> > Bharat Gohil
> > Sr.Software Engineer
> > bharat.gohil@harman.com
> > +919427054633
>
>
>
> --
> Regards,
>
> Oleksandr Tyshchenko
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 14562 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-06 7:01 ` bharat gohil
@ 2017-09-06 10:19 ` Oleksandr Tyshchenko
2017-09-07 13:30 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Oleksandr Tyshchenko @ 2017-09-06 10:19 UTC (permalink / raw)
To: bharat gohil; +Cc: Julien Grall, Stefano Stabellini, Xen Devel
Hi Bharat
On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> Hello Oleksandr,
>
> Thank you very much.It resolved my issue.
Sounds great!
>
> Thanks,
> Bharat
>
> On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko <olekstysh@gmail.com>
> wrote:
>>
>> Hi Bharat
>>
>> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>> > Hello Oleksandr,
>> >
>> > I have corrected GIC settings but no success.Following line disappear
>> > from
>> > log.
>> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000
>> >
>> > Is anything else which can I try.
>> >
>> > I don’t know much about xen internal for ARM architecture. As you
>> > mentioned,
>> >>>Wrong GIC settings might lead to that IPIs won't work as expected. And
>> >>>boot CPU will get stuck waiting for another CPU.
>> >
>> > Can you explain it with some boot sequence and relation with IPI?
>>
>> Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at
>> smp_call_function (one CPU didn't receive interrupt from another one).
>> Next patch helped us to fix this issue:
>> https://patchwork.kernel.org/patch/9163065/
>>
>> I assume the SoC you are working with has "arm,gic-400" compatible GIC.
>> Can you take a look at the patch, maybe it is your case too.
>>
>> >
>> > Thanks,
>> > Bharat
>> >
>> >
>> > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko
>> > <olekstysh@gmail.com>
>> > wrote:
>> >>
>> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com>
>> >> wrote:
>> >> > Hello Oleksandr,
>> >> Hi Bharat
>> >>
>> >> >
>> >> > I had removed A72 cluster and tried to boot only two A35 but I got
>> >> > same
>> >> > error.
>> >> >
>> >> > Is anything added or missing in A35 compare to A53?
>> >> Unfortunately, I don't know.
>> >>
>> >> BTW, did you check your GIC settings in the device-tree?
>> >>
>> >> >
>> >> > Regards,
>> >> > Bharat
>> >> >
>> >> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <ghl.bhrt@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hello Oleksandr,
>> >> >> Thank you very much for your input.
>> >> >>
>> >> >> Yes. agree. I will check by removing A72 core from DT.
>> >> >>
>> >> >> Thanks,
>> >> >> Bharat
>> >> >>
>> >> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
>> >> >> <olekstysh@gmail.com> wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> Not sure that I am a competent person, just my assumptions.
>> >> >>>
>> >> >>> CCed ARM guys.
>> >> >>>
>> >> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil <ghl.bhrt@gmail.com>
>> >> >>> wrote:
>> >> >>> > Hello All
>> >> >>> >
>> >> >>> > I am trying to run Xen on new hardware which has two A35 and one
>> >> >>> > A72
>> >> >>> > core.
>> >> >>> > Xen booted intially but it hangs at
>> >> >>> > smp_call_function(setup_virt_paging_one,
>> >> >>> > (void *)val, 1) function call.
>> >> >>>
>> >> >>> It might be a consequence of that CPU cores are different. And they
>> >> >>> might have different set of features, or even settings.
>> >> >>> And these features/settings the boot CPU has don't compatible with
>> >> >>> other (non-boot) CPUs.
>> >> >>> Can you try not to bringup A72 core (remove it from DT or another
>> >> >>> way), leave only two A35 and see what will happen.
>> >> >>>
>> >> >>> > Find following log of Xen booting,same set of features.
>> >> >>> >
>> >> >>> > - UART enabled -
>> >> >>> > - CPU 00000000 booting -
>> >> >>> > - Current EL 00000008 -
>> >> >>> > - Xen starting at EL2 -
>> >> >>> > - Zero BSS -
>> >> >>> > - Setting up control registers -
>> >> >>> > - Turning on paging -
>> >> >>> > - Ready -
>> >> >>> > (XEN) Checking for initrd in /chosen
>> >> >>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
>> >> >>> > (XEN)
>> >> >>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device Tree
>> >> >>> > (XEN)
>> >> >>> > (XEN) Command line: <NULL>
>> >> >>> Why? Does your device-tree have bootargs?
>> >> >>>
>> >> >>> > (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
>> >> >>> > (XEN) Update BOOTMOD_XEN from 0000000040080000-0000000040194e01
>> >> >>> > =>
>> >> >>> > 00000000bfe01
>> >> >>> > (XEN) Domain heap initialised
>> >> >>> > (XEN) Booting using Device Tree
>> >> >>> > (XEN) Platform: Generic System
>> >> >>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
>> >> >>> > (XEN) Looking for dtuart at "serial0", options ""
>> >> >>> > __ __ _ _ _ ___ _ _
>> >> >>> > _
>> >> >>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __ _|
>> >> >>> > |__
>> >> >>> > | |
>> >> >>> > ___
>> >> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` |
>> >> >>> > '_
>> >> >>> > \|
>> >> >>> > |/ _ \
>> >> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| |
>> >> >>> > |_)
>> >> >>> > | |
>> >> >>> > __/
>> >> >>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
>> >> >>> > |_|___/\__\__,_|_.__/|_|\___|
>> >> >>> >
>> >> >>> > (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
>> >> >>> > (Ubuntu/Linaro7
>> >> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
>> >> >>> > git:9053a74-dirty
>> >> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part
>> >> >>> > 0xd04,
>> >> >>> > rev
>> >> >>> > 0x1
>> >> >>> > (XEN) 64-bit Execution:
>> >> >>> > (XEN) Processor Features: 0000000000002222 0000000000000000
>> >> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32
>> >> >>> > EL0:64+32
>> >> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
>> >> >>> > (XEN) Debug Features: 0000000010305106 0000000000000000
>> >> >>> > (XEN) Auxiliary Features: 0000000000000000 0000000000000000
>> >> >>> > (XEN) Memory Model Features: 0000000000101122 0000000000000000
>> >> >>> > (XEN) ISA Features: 0000000000011120 0000000000000000
>> >> >>> > (XEN) 32-bit Execution:
>> >> >>> > (XEN) Processor Features: 00000131:00011011
>> >> >>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
>> >> >>> > (XEN) Extensions: GenericTimer Security
>> >> >>> > (XEN) Debug Features: 03010066
>> >> >>> > (XEN) Auxiliary Features: 00000000
>> >> >>> > (XEN) Memory Model Features: 10201105 40000000 01260000
>> >> >>> > 02102211
>> >> >>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142
>> >> >>> > 00011121
>> >> >>> > (XEN) Using PSCI-1.0 for SMP bringup
>> >> >>> > (XEN) SMP: Allowing 3 CPUs
>> >> >>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
>> >> >>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
>> >> >>> > 0x2000
>> >> >>> Sounds like GIC settings are not completely correct.
>> >> >>> Wrong GIC settings might lead to that IPIs won't work as expected.
>> >> >>> And
>> >> >>> boot CPU will
>> >> >>> get stuck waiting for another CPU.
>> >> >>> Just double check.
>> >> >>>
>> >> >>> > (XEN) GICv2 initialization:
>> >> >>> > (XEN) gic_dist_addr=0000000010510000
>> >> >>> > (XEN) gic_cpu_addr=0000000010520000
>> >> >>> > (XEN) gic_hyp_addr=0000000010540000
>> >> >>> > (XEN) gic_vcpu_addr=0000000010560000
>> >> >>> > (XEN) gic_maintenance_irq=25
>> >> >>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
>> >> >>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> >> >>> > (XEN) Allocated console ring of 32 KiB.
>> >> >>> > (XEN) Bringing up CPU1
>> >> >>> > - CPU 00000001 booting -
>> >> >>> > - Current EL 00000008 -
>> >> >>> > - Xen starting at EL2 -
>> >> >>> > - Setting up control registers -
>> >> >>> > - Turning on paging -
>> >> >>> > - Ready -
>> >> >>> > (XEN) CPU 1 booted.
>> >> >>> > (XEN) Bringing up CPU2
>> >> >>> > - CPU 00000200 booting -
>> >> >>> > - Current EL 00000008 -
>> >> >>> > - Xen starting at EL2 -
>> >> >>> > - Setting up control registers -
>> >> >>> > - Turning on paging -
>> >> >>> > - Ready -
>> >> >>> > (XEN) CPU 2 booted.
>> >> >>> > (XEN) Brought up 3 CPUs
>> >> >>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
>> >> >>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
>> >> >>> >
>> >> >>> > Can anyone guide me how to debug this problem or what could be
>> >> >>> > wrong
>> >> >>> > here?
>> >> >>> >
>> >> >>> > It looks, writing into VTCR_EL2 hang the system.
>> >> >>> >
>> >> >>> > --
>> >> >>> > Regards,
>> >> >>> > Bharat Gohil
>> >> >>> >
>> >> >>> >
>> >> >>> > _______________________________________________
>> >> >>> > Xen-devel mailing list
>> >> >>> > Xen-devel@lists.xen.org
>> >> >>> > https://lists.xen.org/xen-devel
>> >> >>> >
>> >> >>>
>> >> >>> --
>> >> >>> Regards,
>> >> >>>
>> >> >>> Oleksandr Tyshchenko
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Regards,
>> >> >> Bharat Gohil
>> >> >> Sr.Software Engineer
>> >> >> bharat.gohil@harman.com
>> >> >> +919427054633
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Bharat Gohil
>> >> > Sr.Software Engineer
>> >> > bharat.gohil@harman.com
>> >> > +919427054633
>> >>
>> >>
>> >>
>> >> --
>> >> Regards,
>> >>
>> >> Oleksandr Tyshchenko
>> >
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Bharat Gohil
>> > Sr.Software Engineer
>> > bharat.gohil@harman.com
>> > +919427054633
>>
>>
>>
>> --
>> Regards,
>>
>> Oleksandr Tyshchenko
>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com
> +919427054633
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-06 10:19 ` Oleksandr Tyshchenko
@ 2017-09-07 13:30 ` bharat gohil
2017-09-08 19:19 ` Oleksandr Tyshchenko
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-09-07 13:30 UTC (permalink / raw)
To: Oleksandr Tyshchenko; +Cc: Julien Grall, Stefano Stabellini, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 12288 bytes --]
Hello Olensandr,
I able to boot xen and trying to boot dom0 but there are no console log for
dom0.
following log for xen and it stuck booting dom0.
(XEN) I/O virtualisation disabled
(XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
(XEN) alternatives: Patching with alt table 00000000400d2e08 ->
00000000400d32dc
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 0000000040148158
(XEN) Allocating 1:1 mappings totalling 128MB for dom0:
(XEN) BANK[0] 0x00000048000000-0x00000050000000 (128MB)
(XEN) Grant table range: 0x000000bfe00000-0x000000bfe65000
(XEN) Loading zImage from 0000000040148158 to
0000000048080000-0000000049480000
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x000000004fe00000-0x000000004fe0f31e
(XEN) Scrubbing Free RAM on 1 nodes using 3 CPUs
(XEN) ......done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
to Xen)
(XEN) Freed 272kB init memory.
I have done all the xen configuration in linux kernel 4.9. This kernel
booting fine without xen.
following are the DTB changes,
chosen {
#address-cells = <1>;
#size-cells = <1>;
bootargs = "console=dtuart dtuart=serial0 dom0_mem=128M";
stdout-path = "serial0";
module: module@0 {
compatible = "xen,linux-zimage", "xen,multiboot-module";
reg = <0x40148158 0x1400000>;
bootargs = "console=hvc0,921600n8 earlyprintk=xen debug
ignore_loglevel rw root=/dev/mmcblk0p7";
};
};
Can you tell me how to debug dom0 booting or anything which i can check?
Thanks,
Bharat
On Wed, Sep 6, 2017 at 3:49 PM, Oleksandr Tyshchenko <olekstysh@gmail.com>
wrote:
> Hi Bharat
>
> On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> > Hello Oleksandr,
> >
> > Thank you very much.It resolved my issue.
> Sounds great!
>
> >
> > Thanks,
> > Bharat
> >
> > On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko <
> olekstysh@gmail.com>
> > wrote:
> >>
> >> Hi Bharat
> >>
> >> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil <ghl.bhrt@gmail.com>
> wrote:
> >> > Hello Oleksandr,
> >> >
> >> > I have corrected GIC settings but no success.Following line disappear
> >> > from
> >> > log.
> >> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
> 0x2000
> >> >
> >> > Is anything else which can I try.
> >> >
> >> > I don’t know much about xen internal for ARM architecture. As you
> >> > mentioned,
> >> >>>Wrong GIC settings might lead to that IPIs won't work as expected.
> And
> >> >>>boot CPU will get stuck waiting for another CPU.
> >> >
> >> > Can you explain it with some boot sequence and relation with IPI?
> >>
> >> Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at
> >> smp_call_function (one CPU didn't receive interrupt from another one).
> >> Next patch helped us to fix this issue:
> >> https://patchwork.kernel.org/patch/9163065/
> >>
> >> I assume the SoC you are working with has "arm,gic-400" compatible GIC.
> >> Can you take a look at the patch, maybe it is your case too.
> >>
> >> >
> >> > Thanks,
> >> > Bharat
> >> >
> >> >
> >> > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko
> >> > <olekstysh@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com>
> >> >> wrote:
> >> >> > Hello Oleksandr,
> >> >> Hi Bharat
> >> >>
> >> >> >
> >> >> > I had removed A72 cluster and tried to boot only two A35 but I got
> >> >> > same
> >> >> > error.
> >> >> >
> >> >> > Is anything added or missing in A35 compare to A53?
> >> >> Unfortunately, I don't know.
> >> >>
> >> >> BTW, did you check your GIC settings in the device-tree?
> >> >>
> >> >> >
> >> >> > Regards,
> >> >> > Bharat
> >> >> >
> >> >> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <ghl.bhrt@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hello Oleksandr,
> >> >> >> Thank you very much for your input.
> >> >> >>
> >> >> >> Yes. agree. I will check by removing A72 core from DT.
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Bharat
> >> >> >>
> >> >> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
> >> >> >> <olekstysh@gmail.com> wrote:
> >> >> >>>
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> Not sure that I am a competent person, just my assumptions.
> >> >> >>>
> >> >> >>> CCed ARM guys.
> >> >> >>>
> >> >> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil <
> ghl.bhrt@gmail.com>
> >> >> >>> wrote:
> >> >> >>> > Hello All
> >> >> >>> >
> >> >> >>> > I am trying to run Xen on new hardware which has two A35 and
> one
> >> >> >>> > A72
> >> >> >>> > core.
> >> >> >>> > Xen booted intially but it hangs at
> >> >> >>> > smp_call_function(setup_virt_paging_one,
> >> >> >>> > (void *)val, 1) function call.
> >> >> >>>
> >> >> >>> It might be a consequence of that CPU cores are different. And
> they
> >> >> >>> might have different set of features, or even settings.
> >> >> >>> And these features/settings the boot CPU has don't compatible
> with
> >> >> >>> other (non-boot) CPUs.
> >> >> >>> Can you try not to bringup A72 core (remove it from DT or another
> >> >> >>> way), leave only two A35 and see what will happen.
> >> >> >>>
> >> >> >>> > Find following log of Xen booting,same set of features.
> >> >> >>> >
> >> >> >>> > - UART enabled -
> >> >> >>> > - CPU 00000000 booting -
> >> >> >>> > - Current EL 00000008 -
> >> >> >>> > - Xen starting at EL2 -
> >> >> >>> > - Zero BSS -
> >> >> >>> > - Setting up control registers -
> >> >> >>> > - Turning on paging -
> >> >> >>> > - Ready -
> >> >> >>> > (XEN) Checking for initrd in /chosen
> >> >> >>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
> >> >> >>> > (XEN)
> >> >> >>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device
> Tree
> >> >> >>> > (XEN)
> >> >> >>> > (XEN) Command line: <NULL>
> >> >> >>> Why? Does your device-tree have bootargs?
> >> >> >>>
> >> >> >>> > (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
> >> >> >>> > (XEN) Update BOOTMOD_XEN from 0000000040080000-
> 0000000040194e01
> >> >> >>> > =>
> >> >> >>> > 00000000bfe01
> >> >> >>> > (XEN) Domain heap initialised
> >> >> >>> > (XEN) Booting using Device Tree
> >> >> >>> > (XEN) Platform: Generic System
> >> >> >>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
> >> >> >>> > (XEN) Looking for dtuart at "serial0", options ""
> >> >> >>> > __ __ _ _ _ ___ _
> _
> >> >> >>> > _
> >> >> >>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __ _|
> >> >> >>> > |__
> >> >> >>> > | |
> >> >> >>> > ___
> >> >> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` |
> >> >> >>> > '_
> >> >> >>> > \|
> >> >> >>> > |/ _ \
> >> >> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| |
> >> >> >>> > |_)
> >> >> >>> > | |
> >> >> >>> > __/
> >> >> >>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
> >> >> >>> > |_|___/\__\__,_|_.__/|_|\___|
> >> >> >>> >
> >> >> >>> > (XEN) Xen version 4.10-unstable (bgohil@)
> (aarch64-linux-gnu-gcc
> >> >> >>> > (Ubuntu/Linaro7
> >> >> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
> >> >> >>> > git:9053a74-dirty
> >> >> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part
> >> >> >>> > 0xd04,
> >> >> >>> > rev
> >> >> >>> > 0x1
> >> >> >>> > (XEN) 64-bit Execution:
> >> >> >>> > (XEN) Processor Features: 0000000000002222 0000000000000000
> >> >> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32
> >> >> >>> > EL0:64+32
> >> >> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
> >> >> >>> > (XEN) Debug Features: 0000000010305106 0000000000000000
> >> >> >>> > (XEN) Auxiliary Features: 0000000000000000 0000000000000000
> >> >> >>> > (XEN) Memory Model Features: 0000000000101122
> 0000000000000000
> >> >> >>> > (XEN) ISA Features: 0000000000011120 0000000000000000
> >> >> >>> > (XEN) 32-bit Execution:
> >> >> >>> > (XEN) Processor Features: 00000131:00011011
> >> >> >>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> >> >> >>> > (XEN) Extensions: GenericTimer Security
> >> >> >>> > (XEN) Debug Features: 03010066
> >> >> >>> > (XEN) Auxiliary Features: 00000000
> >> >> >>> > (XEN) Memory Model Features: 10201105 40000000 01260000
> >> >> >>> > 02102211
> >> >> >>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131
> 00011142
> >> >> >>> > 00011121
> >> >> >>> > (XEN) Using PSCI-1.0 for SMP bringup
> >> >> >>> > (XEN) SMP: Allowing 3 CPUs
> >> >> >>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
> >> >> >>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000
> expected
> >> >> >>> > 0x2000
> >> >> >>> Sounds like GIC settings are not completely correct.
> >> >> >>> Wrong GIC settings might lead to that IPIs won't work as
> expected.
> >> >> >>> And
> >> >> >>> boot CPU will
> >> >> >>> get stuck waiting for another CPU.
> >> >> >>> Just double check.
> >> >> >>>
> >> >> >>> > (XEN) GICv2 initialization:
> >> >> >>> > (XEN) gic_dist_addr=0000000010510000
> >> >> >>> > (XEN) gic_cpu_addr=0000000010520000
> >> >> >>> > (XEN) gic_hyp_addr=0000000010540000
> >> >> >>> > (XEN) gic_vcpu_addr=0000000010560000
> >> >> >>> > (XEN) gic_maintenance_irq=25
> >> >> >>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
> >> >> >>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >> >> >>> > (XEN) Allocated console ring of 32 KiB.
> >> >> >>> > (XEN) Bringing up CPU1
> >> >> >>> > - CPU 00000001 booting -
> >> >> >>> > - Current EL 00000008 -
> >> >> >>> > - Xen starting at EL2 -
> >> >> >>> > - Setting up control registers -
> >> >> >>> > - Turning on paging -
> >> >> >>> > - Ready -
> >> >> >>> > (XEN) CPU 1 booted.
> >> >> >>> > (XEN) Bringing up CPU2
> >> >> >>> > - CPU 00000200 booting -
> >> >> >>> > - Current EL 00000008 -
> >> >> >>> > - Xen starting at EL2 -
> >> >> >>> > - Setting up control registers -
> >> >> >>> > - Turning on paging -
> >> >> >>> > - Ready -
> >> >> >>> > (XEN) CPU 2 booted.
> >> >> >>> > (XEN) Brought up 3 CPUs
> >> >> >>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> >> >> >>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> >> >> >>> >
> >> >> >>> > Can anyone guide me how to debug this problem or what could be
> >> >> >>> > wrong
> >> >> >>> > here?
> >> >> >>> >
> >> >> >>> > It looks, writing into VTCR_EL2 hang the system.
> >> >> >>> >
> >> >> >>> > --
> >> >> >>> > Regards,
> >> >> >>> > Bharat Gohil
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > _______________________________________________
> >> >> >>> > Xen-devel mailing list
> >> >> >>> > Xen-devel@lists.xen.org
> >> >> >>> > https://lists.xen.org/xen-devel
> >> >> >>> >
> >> >> >>>
> >> >> >>> --
> >> >> >>> Regards,
> >> >> >>>
> >> >> >>> Oleksandr Tyshchenko
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Regards,
> >> >> >> Bharat Gohil
> >> >> >> Sr.Software Engineer
> >> >> >> bharat.gohil@harman.com
> >> >> >> +919427054633
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Regards,
> >> >> > Bharat Gohil
> >> >> > Sr.Software Engineer
> >> >> > bharat.gohil@harman.com
> >> >> > +919427054633
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Regards,
> >> >>
> >> >> Oleksandr Tyshchenko
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Bharat Gohil
> >> > Sr.Software Engineer
> >> > bharat.gohil@harman.com
> >> > +919427054633
> >>
> >>
> >>
> >> --
> >> Regards,
> >>
> >> Oleksandr Tyshchenko
> >
> >
> >
> >
> > --
> > Regards,
> > Bharat Gohil
> > Sr.Software Engineer
> > bharat.gohil@harman.com
> > +919427054633
>
>
>
> --
> Regards,
>
> Oleksandr Tyshchenko
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 20196 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-07 13:30 ` bharat gohil
@ 2017-09-08 19:19 ` Oleksandr Tyshchenko
2017-09-18 14:46 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 36+ messages in thread
From: Oleksandr Tyshchenko @ 2017-09-08 19:19 UTC (permalink / raw)
To: bharat gohil; +Cc: Julien Grall, Stefano Stabellini, Xen Devel
Hi Bharat
On Thu, Sep 7, 2017 at 4:30 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> Hello Olensandr,
>
> I able to boot xen and trying to boot dom0 but there are no console log for
> dom0.
>
> following log for xen and it stuck booting dom0.
>
> (XEN) I/O virtualisation disabled
> (XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
> (XEN) alternatives: Patching with alt table 00000000400d2e08 ->
> 00000000400d32dc
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading kernel from boot module @ 0000000040148158
> (XEN) Allocating 1:1 mappings totalling 128MB for dom0:
> (XEN) BANK[0] 0x00000048000000-0x00000050000000 (128MB)
> (XEN) Grant table range: 0x000000bfe00000-0x000000bfe65000
> (XEN) Loading zImage from 0000000040148158 to
> 0000000048080000-0000000049480000
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading dom0 DTB to 0x000000004fe00000-0x000000004fe0f31e
> (XEN) Scrubbing Free RAM on 1 nodes using 3 CPUs
> (XEN) ......done.
> (XEN) Initial low memory virq threshold set at 0x4000 pages.
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to
> Xen)
> (XEN) Freed 272kB init memory.
>
> I have done all the xen configuration in linux kernel 4.9. This kernel
> booting fine without xen.
>
> following are the DTB changes,
>
> chosen {
> #address-cells = <1>;
> #size-cells = <1>;
> bootargs = "console=dtuart dtuart=serial0 dom0_mem=128M";
> stdout-path = "serial0";
> module: module@0 {
> compatible = "xen,linux-zimage", "xen,multiboot-module";
> reg = <0x40148158 0x1400000>;
> bootargs = "console=hvc0,921600n8 earlyprintk=xen debug
> ignore_loglevel rw root=/dev/mmcblk0p7";
> };
>
> };
>
> Can you tell me how to debug dom0 booting or anything which i can check?
Don't now much about "debug dom0 booting", I leave it for competent people.
Looks weird, even with earlyprintk no logs.
Do you have DEBUG_LL and all related options enabled in your dom0 kernel config?
1. Check that following options are enabled in your kernel config file:
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
2. Check that dom0 kernel doesn't disable clock for console.
BTW, could you post full Xen log, kernel config and device-tree you are using?
If you have some changes on top of Xen, post them too.
These may help people to identify what is wrong.
>
>
> Thanks,
> Bharat
>
> On Wed, Sep 6, 2017 at 3:49 PM, Oleksandr Tyshchenko <olekstysh@gmail.com>
> wrote:
>>
>> Hi Bharat
>>
>> On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>> > Hello Oleksandr,
>> >
>> > Thank you very much.It resolved my issue.
>> Sounds great!
>>
>> >
>> > Thanks,
>> > Bharat
>> >
>> > On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko
>> > <olekstysh@gmail.com>
>> > wrote:
>> >>
>> >> Hi Bharat
>> >>
>> >> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil <ghl.bhrt@gmail.com>
>> >> wrote:
>> >> > Hello Oleksandr,
>> >> >
>> >> > I have corrected GIC settings but no success.Following line
>> >> > disappear
>> >> > from
>> >> > log.
>> >> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
>> >> >>> 0x2000
>> >> >
>> >> > Is anything else which can I try.
>> >> >
>> >> > I don’t know much about xen internal for ARM architecture. As you
>> >> > mentioned,
>> >> >>>Wrong GIC settings might lead to that IPIs won't work as expected.
>> >> >>> And
>> >> >>>boot CPU will get stuck waiting for another CPU.
>> >> >
>> >> > Can you explain it with some boot sequence and relation with IPI?
>> >>
>> >> Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at
>> >> smp_call_function (one CPU didn't receive interrupt from another one).
>> >> Next patch helped us to fix this issue:
>> >> https://patchwork.kernel.org/patch/9163065/
>> >>
>> >> I assume the SoC you are working with has "arm,gic-400" compatible GIC.
>> >> Can you take a look at the patch, maybe it is your case too.
>> >>
>> >> >
>> >> > Thanks,
>> >> > Bharat
>> >> >
>> >> >
>> >> > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko
>> >> > <olekstysh@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com>
>> >> >> wrote:
>> >> >> > Hello Oleksandr,
>> >> >> Hi Bharat
>> >> >>
>> >> >> >
>> >> >> > I had removed A72 cluster and tried to boot only two A35 but I got
>> >> >> > same
>> >> >> > error.
>> >> >> >
>> >> >> > Is anything added or missing in A35 compare to A53?
>> >> >> Unfortunately, I don't know.
>> >> >>
>> >> >> BTW, did you check your GIC settings in the device-tree?
>> >> >>
>> >> >> >
>> >> >> > Regards,
>> >> >> > Bharat
>> >> >> >
>> >> >> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <ghl.bhrt@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hello Oleksandr,
>> >> >> >> Thank you very much for your input.
>> >> >> >>
>> >> >> >> Yes. agree. I will check by removing A72 core from DT.
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >> Bharat
>> >> >> >>
>> >> >> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
>> >> >> >> <olekstysh@gmail.com> wrote:
>> >> >> >>>
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> Not sure that I am a competent person, just my assumptions.
>> >> >> >>>
>> >> >> >>> CCed ARM guys.
>> >> >> >>>
>> >> >> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil
>> >> >> >>> <ghl.bhrt@gmail.com>
>> >> >> >>> wrote:
>> >> >> >>> > Hello All
>> >> >> >>> >
>> >> >> >>> > I am trying to run Xen on new hardware which has two A35 and
>> >> >> >>> > one
>> >> >> >>> > A72
>> >> >> >>> > core.
>> >> >> >>> > Xen booted intially but it hangs at
>> >> >> >>> > smp_call_function(setup_virt_paging_one,
>> >> >> >>> > (void *)val, 1) function call.
>> >> >> >>>
>> >> >> >>> It might be a consequence of that CPU cores are different. And
>> >> >> >>> they
>> >> >> >>> might have different set of features, or even settings.
>> >> >> >>> And these features/settings the boot CPU has don't compatible
>> >> >> >>> with
>> >> >> >>> other (non-boot) CPUs.
>> >> >> >>> Can you try not to bringup A72 core (remove it from DT or
>> >> >> >>> another
>> >> >> >>> way), leave only two A35 and see what will happen.
>> >> >> >>>
>> >> >> >>> > Find following log of Xen booting,same set of features.
>> >> >> >>> >
>> >> >> >>> > - UART enabled -
>> >> >> >>> > - CPU 00000000 booting -
>> >> >> >>> > - Current EL 00000008 -
>> >> >> >>> > - Xen starting at EL2 -
>> >> >> >>> > - Zero BSS -
>> >> >> >>> > - Setting up control registers -
>> >> >> >>> > - Turning on paging -
>> >> >> >>> > - Ready -
>> >> >> >>> > (XEN) Checking for initrd in /chosen
>> >> >> >>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
>> >> >> >>> > (XEN)
>> >> >> >>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device
>> >> >> >>> > Tree
>> >> >> >>> > (XEN)
>> >> >> >>> > (XEN) Command line: <NULL>
>> >> >> >>> Why? Does your device-tree have bootargs?
>> >> >> >>>
>> >> >> >>> > (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
>> >> >> >>> > (XEN) Update BOOTMOD_XEN from
>> >> >> >>> > 0000000040080000-0000000040194e01
>> >> >> >>> > =>
>> >> >> >>> > 00000000bfe01
>> >> >> >>> > (XEN) Domain heap initialised
>> >> >> >>> > (XEN) Booting using Device Tree
>> >> >> >>> > (XEN) Platform: Generic System
>> >> >> >>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
>> >> >> >>> > (XEN) Looking for dtuart at "serial0", options ""
>> >> >> >>> > __ __ _ _ _ ___ _
>> >> >> >>> > _
>> >> >> >>> > _
>> >> >> >>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __
>> >> >> >>> > _|
>> >> >> >>> > |__
>> >> >> >>> > | |
>> >> >> >>> > ___
>> >> >> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _`
>> >> >> >>> > |
>> >> >> >>> > '_
>> >> >> >>> > \|
>> >> >> >>> > |/ _ \
>> >> >> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_|
>> >> >> >>> > |
>> >> >> >>> > |_)
>> >> >> >>> > | |
>> >> >> >>> > __/
>> >> >> >>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
>> >> >> >>> > |_|___/\__\__,_|_.__/|_|\___|
>> >> >> >>> >
>> >> >> >>> > (XEN) Xen version 4.10-unstable (bgohil@)
>> >> >> >>> > (aarch64-linux-gnu-gcc
>> >> >> >>> > (Ubuntu/Linaro7
>> >> >> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
>> >> >> >>> > git:9053a74-dirty
>> >> >> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part
>> >> >> >>> > 0xd04,
>> >> >> >>> > rev
>> >> >> >>> > 0x1
>> >> >> >>> > (XEN) 64-bit Execution:
>> >> >> >>> > (XEN) Processor Features: 0000000000002222 0000000000000000
>> >> >> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32
>> >> >> >>> > EL0:64+32
>> >> >> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
>> >> >> >>> > (XEN) Debug Features: 0000000010305106 0000000000000000
>> >> >> >>> > (XEN) Auxiliary Features: 0000000000000000 0000000000000000
>> >> >> >>> > (XEN) Memory Model Features: 0000000000101122
>> >> >> >>> > 0000000000000000
>> >> >> >>> > (XEN) ISA Features: 0000000000011120 0000000000000000
>> >> >> >>> > (XEN) 32-bit Execution:
>> >> >> >>> > (XEN) Processor Features: 00000131:00011011
>> >> >> >>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
>> >> >> >>> > (XEN) Extensions: GenericTimer Security
>> >> >> >>> > (XEN) Debug Features: 03010066
>> >> >> >>> > (XEN) Auxiliary Features: 00000000
>> >> >> >>> > (XEN) Memory Model Features: 10201105 40000000 01260000
>> >> >> >>> > 02102211
>> >> >> >>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131
>> >> >> >>> > 00011142
>> >> >> >>> > 00011121
>> >> >> >>> > (XEN) Using PSCI-1.0 for SMP bringup
>> >> >> >>> > (XEN) SMP: Allowing 3 CPUs
>> >> >> >>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000
>> >> >> >>> > KHz
>> >> >> >>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000
>> >> >> >>> > expected
>> >> >> >>> > 0x2000
>> >> >> >>> Sounds like GIC settings are not completely correct.
>> >> >> >>> Wrong GIC settings might lead to that IPIs won't work as
>> >> >> >>> expected.
>> >> >> >>> And
>> >> >> >>> boot CPU will
>> >> >> >>> get stuck waiting for another CPU.
>> >> >> >>> Just double check.
>> >> >> >>>
>> >> >> >>> > (XEN) GICv2 initialization:
>> >> >> >>> > (XEN) gic_dist_addr=0000000010510000
>> >> >> >>> > (XEN) gic_cpu_addr=0000000010520000
>> >> >> >>> > (XEN) gic_hyp_addr=0000000010540000
>> >> >> >>> > (XEN) gic_vcpu_addr=0000000010560000
>> >> >> >>> > (XEN) gic_maintenance_irq=25
>> >> >> >>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
>> >> >> >>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> >> >> >>> > (XEN) Allocated console ring of 32 KiB.
>> >> >> >>> > (XEN) Bringing up CPU1
>> >> >> >>> > - CPU 00000001 booting -
>> >> >> >>> > - Current EL 00000008 -
>> >> >> >>> > - Xen starting at EL2 -
>> >> >> >>> > - Setting up control registers -
>> >> >> >>> > - Turning on paging -
>> >> >> >>> > - Ready -
>> >> >> >>> > (XEN) CPU 1 booted.
>> >> >> >>> > (XEN) Bringing up CPU2
>> >> >> >>> > - CPU 00000200 booting -
>> >> >> >>> > - Current EL 00000008 -
>> >> >> >>> > - Xen starting at EL2 -
>> >> >> >>> > - Setting up control registers -
>> >> >> >>> > - Turning on paging -
>> >> >> >>> > - Ready -
>> >> >> >>> > (XEN) CPU 2 booted.
>> >> >> >>> > (XEN) Brought up 3 CPUs
>> >> >> >>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
>> >> >> >>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
>> >> >> >>> >
>> >> >> >>> > Can anyone guide me how to debug this problem or what could be
>> >> >> >>> > wrong
>> >> >> >>> > here?
>> >> >> >>> >
>> >> >> >>> > It looks, writing into VTCR_EL2 hang the system.
>> >> >> >>> >
>> >> >> >>> > --
>> >> >> >>> > Regards,
>> >> >> >>> > Bharat Gohil
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > _______________________________________________
>> >> >> >>> > Xen-devel mailing list
>> >> >> >>> > Xen-devel@lists.xen.org
>> >> >> >>> > https://lists.xen.org/xen-devel
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> Regards,
>> >> >> >>>
>> >> >> >>> Oleksandr Tyshchenko
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Regards,
>> >> >> >> Bharat Gohil
>> >> >> >> Sr.Software Engineer
>> >> >> >> bharat.gohil@harman.com
>> >> >> >> +919427054633
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Regards,
>> >> >> > Bharat Gohil
>> >> >> > Sr.Software Engineer
>> >> >> > bharat.gohil@harman.com
>> >> >> > +919427054633
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Regards,
>> >> >>
>> >> >> Oleksandr Tyshchenko
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Bharat Gohil
>> >> > Sr.Software Engineer
>> >> > bharat.gohil@harman.com
>> >> > +919427054633
>> >>
>> >>
>> >>
>> >> --
>> >> Regards,
>> >>
>> >> Oleksandr Tyshchenko
>> >
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Bharat Gohil
>> > Sr.Software Engineer
>> > bharat.gohil@harman.com
>> > +919427054633
>>
>>
>>
>> --
>> Regards,
>>
>> Oleksandr Tyshchenko
>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com
> +919427054633
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-08 19:19 ` Oleksandr Tyshchenko
@ 2017-09-18 14:46 ` Konrad Rzeszutek Wilk
2017-09-22 10:00 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Konrad Rzeszutek Wilk @ 2017-09-18 14:46 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: Julien Grall, Stefano Stabellini, bharat gohil, Xen Devel
On Fri, Sep 08, 2017 at 10:19:55PM +0300, Oleksandr Tyshchenko wrote:
> Hi Bharat
>
> On Thu, Sep 7, 2017 at 4:30 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> > Hello Olensandr,
> >
> > I able to boot xen and trying to boot dom0 but there are no console log for
> > dom0.
> >
> > following log for xen and it stuck booting dom0.
> >
> > (XEN) I/O virtualisation disabled
> > (XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
> > (XEN) alternatives: Patching with alt table 00000000400d2e08 ->
> > 00000000400d32dc
> > (XEN) *** LOADING DOMAIN 0 ***
> > (XEN) Loading kernel from boot module @ 0000000040148158
> > (XEN) Allocating 1:1 mappings totalling 128MB for dom0:
> > (XEN) BANK[0] 0x00000048000000-0x00000050000000 (128MB)
> > (XEN) Grant table range: 0x000000bfe00000-0x000000bfe65000
> > (XEN) Loading zImage from 0000000040148158 to
> > 0000000048080000-0000000049480000
> > (XEN) Allocating PPI 16 for event channel interrupt
> > (XEN) Loading dom0 DTB to 0x000000004fe00000-0x000000004fe0f31e
> > (XEN) Scrubbing Free RAM on 1 nodes using 3 CPUs
> > (XEN) ......done.
> > (XEN) Initial low memory virq threshold set at 0x4000 pages.
> > (XEN) Std. Loglevel: All
> > (XEN) Guest Loglevel: All
> > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to
> > Xen)
> > (XEN) Freed 272kB init memory.
> >
> > I have done all the xen configuration in linux kernel 4.9. This kernel
> > booting fine without xen.
> >
> > following are the DTB changes,
> >
> > chosen {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > bootargs = "console=dtuart dtuart=serial0 dom0_mem=128M";
> > stdout-path = "serial0";
> > module: module@0 {
> > compatible = "xen,linux-zimage", "xen,multiboot-module";
> > reg = <0x40148158 0x1400000>;
> > bootargs = "console=hvc0,921600n8 earlyprintk=xen debug
It should be just 'console=hvc0', not 'console=hvc0,921600n8'
> > ignore_loglevel rw root=/dev/mmcblk0p7";
> > };
> >
> > };
> >
> > Can you tell me how to debug dom0 booting or anything which i can check?
>
> Don't now much about "debug dom0 booting", I leave it for competent people.
>
> Looks weird, even with earlyprintk no logs.
> Do you have DEBUG_LL and all related options enabled in your dom0 kernel config?
>
> 1. Check that following options are enabled in your kernel config file:
>
> CONFIG_HVC_XEN=y
> CONFIG_HVC_XEN_FRONTEND=y
>
> 2. Check that dom0 kernel doesn't disable clock for console.
>
> BTW, could you post full Xen log, kernel config and device-tree you are using?
> If you have some changes on top of Xen, post them too.
> These may help people to identify what is wrong.
>
> >
> >
> > Thanks,
> > Bharat
> >
> > On Wed, Sep 6, 2017 at 3:49 PM, Oleksandr Tyshchenko <olekstysh@gmail.com>
> > wrote:
> >>
> >> Hi Bharat
> >>
> >> On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> >> > Hello Oleksandr,
> >> >
> >> > Thank you very much.It resolved my issue.
> >> Sounds great!
> >>
> >> >
> >> > Thanks,
> >> > Bharat
> >> >
> >> > On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko
> >> > <olekstysh@gmail.com>
> >> > wrote:
> >> >>
> >> >> Hi Bharat
> >> >>
> >> >> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil <ghl.bhrt@gmail.com>
> >> >> wrote:
> >> >> > Hello Oleksandr,
> >> >> >
> >> >> > I have corrected GIC settings but no success.Following line
> >> >> > disappear
> >> >> > from
> >> >> > log.
> >> >> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
> >> >> >>> 0x2000
> >> >> >
> >> >> > Is anything else which can I try.
> >> >> >
> >> >> > I don’t know much about xen internal for ARM architecture. As you
> >> >> > mentioned,
> >> >> >>>Wrong GIC settings might lead to that IPIs won't work as expected.
> >> >> >>> And
> >> >> >>>boot CPU will get stuck waiting for another CPU.
> >> >> >
> >> >> > Can you explain it with some boot sequence and relation with IPI?
> >> >>
> >> >> Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at
> >> >> smp_call_function (one CPU didn't receive interrupt from another one).
> >> >> Next patch helped us to fix this issue:
> >> >> https://patchwork.kernel.org/patch/9163065/
> >> >>
> >> >> I assume the SoC you are working with has "arm,gic-400" compatible GIC.
> >> >> Can you take a look at the patch, maybe it is your case too.
> >> >>
> >> >> >
> >> >> > Thanks,
> >> >> > Bharat
> >> >> >
> >> >> >
> >> >> > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko
> >> >> > <olekstysh@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com>
> >> >> >> wrote:
> >> >> >> > Hello Oleksandr,
> >> >> >> Hi Bharat
> >> >> >>
> >> >> >> >
> >> >> >> > I had removed A72 cluster and tried to boot only two A35 but I got
> >> >> >> > same
> >> >> >> > error.
> >> >> >> >
> >> >> >> > Is anything added or missing in A35 compare to A53?
> >> >> >> Unfortunately, I don't know.
> >> >> >>
> >> >> >> BTW, did you check your GIC settings in the device-tree?
> >> >> >>
> >> >> >> >
> >> >> >> > Regards,
> >> >> >> > Bharat
> >> >> >> >
> >> >> >> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <ghl.bhrt@gmail.com>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> Hello Oleksandr,
> >> >> >> >> Thank you very much for your input.
> >> >> >> >>
> >> >> >> >> Yes. agree. I will check by removing A72 core from DT.
> >> >> >> >>
> >> >> >> >> Thanks,
> >> >> >> >> Bharat
> >> >> >> >>
> >> >> >> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
> >> >> >> >> <olekstysh@gmail.com> wrote:
> >> >> >> >>>
> >> >> >> >>> Hi,
> >> >> >> >>>
> >> >> >> >>> Not sure that I am a competent person, just my assumptions.
> >> >> >> >>>
> >> >> >> >>> CCed ARM guys.
> >> >> >> >>>
> >> >> >> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil
> >> >> >> >>> <ghl.bhrt@gmail.com>
> >> >> >> >>> wrote:
> >> >> >> >>> > Hello All
> >> >> >> >>> >
> >> >> >> >>> > I am trying to run Xen on new hardware which has two A35 and
> >> >> >> >>> > one
> >> >> >> >>> > A72
> >> >> >> >>> > core.
> >> >> >> >>> > Xen booted intially but it hangs at
> >> >> >> >>> > smp_call_function(setup_virt_paging_one,
> >> >> >> >>> > (void *)val, 1) function call.
> >> >> >> >>>
> >> >> >> >>> It might be a consequence of that CPU cores are different. And
> >> >> >> >>> they
> >> >> >> >>> might have different set of features, or even settings.
> >> >> >> >>> And these features/settings the boot CPU has don't compatible
> >> >> >> >>> with
> >> >> >> >>> other (non-boot) CPUs.
> >> >> >> >>> Can you try not to bringup A72 core (remove it from DT or
> >> >> >> >>> another
> >> >> >> >>> way), leave only two A35 and see what will happen.
> >> >> >> >>>
> >> >> >> >>> > Find following log of Xen booting,same set of features.
> >> >> >> >>> >
> >> >> >> >>> > - UART enabled -
> >> >> >> >>> > - CPU 00000000 booting -
> >> >> >> >>> > - Current EL 00000008 -
> >> >> >> >>> > - Xen starting at EL2 -
> >> >> >> >>> > - Zero BSS -
> >> >> >> >>> > - Setting up control registers -
> >> >> >> >>> > - Turning on paging -
> >> >> >> >>> > - Ready -
> >> >> >> >>> > (XEN) Checking for initrd in /chosen
> >> >> >> >>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
> >> >> >> >>> > (XEN)
> >> >> >> >>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a Device
> >> >> >> >>> > Tree
> >> >> >> >>> > (XEN)
> >> >> >> >>> > (XEN) Command line: <NULL>
> >> >> >> >>> Why? Does your device-tree have bootargs?
> >> >> >> >>>
> >> >> >> >>> > (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000
> >> >> >> >>> > (XEN) Update BOOTMOD_XEN from
> >> >> >> >>> > 0000000040080000-0000000040194e01
> >> >> >> >>> > =>
> >> >> >> >>> > 00000000bfe01
> >> >> >> >>> > (XEN) Domain heap initialised
> >> >> >> >>> > (XEN) Booting using Device Tree
> >> >> >> >>> > (XEN) Platform: Generic System
> >> >> >> >>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
> >> >> >> >>> > (XEN) Looking for dtuart at "serial0", options ""
> >> >> >> >>> > __ __ _ _ _ ___ _
> >> >> >> >>> > _
> >> >> >> >>> > _
> >> >> >> >>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_ __
> >> >> >> >>> > _|
> >> >> >> >>> > |__
> >> >> >> >>> > | |
> >> >> >> >>> > ___
> >> >> >> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _`
> >> >> >> >>> > |
> >> >> >> >>> > '_
> >> >> >> >>> > \|
> >> >> >> >>> > |/ _ \
> >> >> >> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_|
> >> >> >> >>> > |
> >> >> >> >>> > |_)
> >> >> >> >>> > | |
> >> >> >> >>> > __/
> >> >> >> >>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
> >> >> >> >>> > |_|___/\__\__,_|_.__/|_|\___|
> >> >> >> >>> >
> >> >> >> >>> > (XEN) Xen version 4.10-unstable (bgohil@)
> >> >> >> >>> > (aarch64-linux-gnu-gcc
> >> >> >> >>> > (Ubuntu/Linaro7
> >> >> >> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
> >> >> >> >>> > git:9053a74-dirty
> >> >> >> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part
> >> >> >> >>> > 0xd04,
> >> >> >> >>> > rev
> >> >> >> >>> > 0x1
> >> >> >> >>> > (XEN) 64-bit Execution:
> >> >> >> >>> > (XEN) Processor Features: 0000000000002222 0000000000000000
> >> >> >> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32
> >> >> >> >>> > EL0:64+32
> >> >> >> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
> >> >> >> >>> > (XEN) Debug Features: 0000000010305106 0000000000000000
> >> >> >> >>> > (XEN) Auxiliary Features: 0000000000000000 0000000000000000
> >> >> >> >>> > (XEN) Memory Model Features: 0000000000101122
> >> >> >> >>> > 0000000000000000
> >> >> >> >>> > (XEN) ISA Features: 0000000000011120 0000000000000000
> >> >> >> >>> > (XEN) 32-bit Execution:
> >> >> >> >>> > (XEN) Processor Features: 00000131:00011011
> >> >> >> >>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> >> >> >> >>> > (XEN) Extensions: GenericTimer Security
> >> >> >> >>> > (XEN) Debug Features: 03010066
> >> >> >> >>> > (XEN) Auxiliary Features: 00000000
> >> >> >> >>> > (XEN) Memory Model Features: 10201105 40000000 01260000
> >> >> >> >>> > 02102211
> >> >> >> >>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131
> >> >> >> >>> > 00011142
> >> >> >> >>> > 00011121
> >> >> >> >>> > (XEN) Using PSCI-1.0 for SMP bringup
> >> >> >> >>> > (XEN) SMP: Allowing 3 CPUs
> >> >> >> >>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000
> >> >> >> >>> > KHz
> >> >> >> >>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000
> >> >> >> >>> > expected
> >> >> >> >>> > 0x2000
> >> >> >> >>> Sounds like GIC settings are not completely correct.
> >> >> >> >>> Wrong GIC settings might lead to that IPIs won't work as
> >> >> >> >>> expected.
> >> >> >> >>> And
> >> >> >> >>> boot CPU will
> >> >> >> >>> get stuck waiting for another CPU.
> >> >> >> >>> Just double check.
> >> >> >> >>>
> >> >> >> >>> > (XEN) GICv2 initialization:
> >> >> >> >>> > (XEN) gic_dist_addr=0000000010510000
> >> >> >> >>> > (XEN) gic_cpu_addr=0000000010520000
> >> >> >> >>> > (XEN) gic_hyp_addr=0000000010540000
> >> >> >> >>> > (XEN) gic_vcpu_addr=0000000010560000
> >> >> >> >>> > (XEN) gic_maintenance_irq=25
> >> >> >> >>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
> >> >> >> >>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >> >> >> >>> > (XEN) Allocated console ring of 32 KiB.
> >> >> >> >>> > (XEN) Bringing up CPU1
> >> >> >> >>> > - CPU 00000001 booting -
> >> >> >> >>> > - Current EL 00000008 -
> >> >> >> >>> > - Xen starting at EL2 -
> >> >> >> >>> > - Setting up control registers -
> >> >> >> >>> > - Turning on paging -
> >> >> >> >>> > - Ready -
> >> >> >> >>> > (XEN) CPU 1 booted.
> >> >> >> >>> > (XEN) Bringing up CPU2
> >> >> >> >>> > - CPU 00000200 booting -
> >> >> >> >>> > - Current EL 00000008 -
> >> >> >> >>> > - Xen starting at EL2 -
> >> >> >> >>> > - Setting up control registers -
> >> >> >> >>> > - Turning on paging -
> >> >> >> >>> > - Ready -
> >> >> >> >>> > (XEN) CPU 2 booted.
> >> >> >> >>> > (XEN) Brought up 3 CPUs
> >> >> >> >>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> >> >> >> >>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> >> >> >> >>> >
> >> >> >> >>> > Can anyone guide me how to debug this problem or what could be
> >> >> >> >>> > wrong
> >> >> >> >>> > here?
> >> >> >> >>> >
> >> >> >> >>> > It looks, writing into VTCR_EL2 hang the system.
> >> >> >> >>> >
> >> >> >> >>> > --
> >> >> >> >>> > Regards,
> >> >> >> >>> > Bharat Gohil
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> > _______________________________________________
> >> >> >> >>> > Xen-devel mailing list
> >> >> >> >>> > Xen-devel@lists.xen.org
> >> >> >> >>> > https://lists.xen.org/xen-devel
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >> >>> --
> >> >> >> >>> Regards,
> >> >> >> >>>
> >> >> >> >>> Oleksandr Tyshchenko
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Regards,
> >> >> >> >> Bharat Gohil
> >> >> >> >> Sr.Software Engineer
> >> >> >> >> bharat.gohil@harman.com
> >> >> >> >> +919427054633
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Regards,
> >> >> >> > Bharat Gohil
> >> >> >> > Sr.Software Engineer
> >> >> >> > bharat.gohil@harman.com
> >> >> >> > +919427054633
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Regards,
> >> >> >>
> >> >> >> Oleksandr Tyshchenko
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Regards,
> >> >> > Bharat Gohil
> >> >> > Sr.Software Engineer
> >> >> > bharat.gohil@harman.com
> >> >> > +919427054633
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Regards,
> >> >>
> >> >> Oleksandr Tyshchenko
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Bharat Gohil
> >> > Sr.Software Engineer
> >> > bharat.gohil@harman.com
> >> > +919427054633
> >>
> >>
> >>
> >> --
> >> Regards,
> >>
> >> Oleksandr Tyshchenko
> >
> >
> >
> >
> > --
> > Regards,
> > Bharat Gohil
> > Sr.Software Engineer
> > bharat.gohil@harman.com
> > +919427054633
>
>
>
> --
> Regards,
>
> Oleksandr Tyshchenko
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-18 14:46 ` Konrad Rzeszutek Wilk
@ 2017-09-22 10:00 ` bharat gohil
2017-09-22 13:43 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-09-22 10:00 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Oleksandr Tyshchenko, Julien Grall, Stefano Stabellini, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 16155 bytes --]
Hello Wilk,
I had try 'console=hvc0' but no success.
@Oleksandr: At this moment it is difficult to share any file of guest.
It would be helpful if anyone provide me general technique to debug dom0
bringup issue.
Thanks,
Bharat
On Mon, Sep 18, 2017 at 8:16 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:
> On Fri, Sep 08, 2017 at 10:19:55PM +0300, Oleksandr Tyshchenko wrote:
> > Hi Bharat
> >
> > On Thu, Sep 7, 2017 at 4:30 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> > > Hello Olensandr,
> > >
> > > I able to boot xen and trying to boot dom0 but there are no console
> log for
> > > dom0.
> > >
> > > following log for xen and it stuck booting dom0.
> > >
> > > (XEN) I/O virtualisation disabled
> > > (XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
> > > (XEN) alternatives: Patching with alt table 00000000400d2e08 ->
> > > 00000000400d32dc
> > > (XEN) *** LOADING DOMAIN 0 ***
> > > (XEN) Loading kernel from boot module @ 0000000040148158
> > > (XEN) Allocating 1:1 mappings totalling 128MB for dom0:
> > > (XEN) BANK[0] 0x00000048000000-0x00000050000000 (128MB)
> > > (XEN) Grant table range: 0x000000bfe00000-0x000000bfe65000
> > > (XEN) Loading zImage from 0000000040148158 to
> > > 0000000048080000-0000000049480000
> > > (XEN) Allocating PPI 16 for event channel interrupt
> > > (XEN) Loading dom0 DTB to 0x000000004fe00000-0x000000004fe0f31e
> > > (XEN) Scrubbing Free RAM on 1 nodes using 3 CPUs
> > > (XEN) ......done.
> > > (XEN) Initial low memory virq threshold set at 0x4000 pages.
> > > (XEN) Std. Loglevel: All
> > > (XEN) Guest Loglevel: All
> > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to
> > > Xen)
> > > (XEN) Freed 272kB init memory.
> > >
> > > I have done all the xen configuration in linux kernel 4.9. This kernel
> > > booting fine without xen.
> > >
> > > following are the DTB changes,
> > >
> > > chosen {
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > > bootargs = "console=dtuart dtuart=serial0 dom0_mem=128M";
> > > stdout-path = "serial0";
> > > module: module@0 {
> > > compatible = "xen,linux-zimage", "xen,multiboot-module";
> > > reg = <0x40148158 0x1400000>;
> > > bootargs = "console=hvc0,921600n8 earlyprintk=xen debug
>
> It should be just 'console=hvc0', not 'console=hvc0,921600n8'
>
> > > ignore_loglevel rw root=/dev/mmcblk0p7";
> > > };
> > >
> > > };
> > >
> > > Can you tell me how to debug dom0 booting or anything which i can
> check?
> >
> > Don't now much about "debug dom0 booting", I leave it for competent
> people.
> >
> > Looks weird, even with earlyprintk no logs.
> > Do you have DEBUG_LL and all related options enabled in your dom0 kernel
> config?
> >
> > 1. Check that following options are enabled in your kernel config file:
> >
> > CONFIG_HVC_XEN=y
> > CONFIG_HVC_XEN_FRONTEND=y
> >
> > 2. Check that dom0 kernel doesn't disable clock for console.
> >
> > BTW, could you post full Xen log, kernel config and device-tree you are
> using?
> > If you have some changes on top of Xen, post them too.
> > These may help people to identify what is wrong.
> >
> > >
> > >
> > > Thanks,
> > > Bharat
> > >
> > > On Wed, Sep 6, 2017 at 3:49 PM, Oleksandr Tyshchenko <
> olekstysh@gmail.com>
> > > wrote:
> > >>
> > >> Hi Bharat
> > >>
> > >> On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil <ghl.bhrt@gmail.com>
> wrote:
> > >> > Hello Oleksandr,
> > >> >
> > >> > Thank you very much.It resolved my issue.
> > >> Sounds great!
> > >>
> > >> >
> > >> > Thanks,
> > >> > Bharat
> > >> >
> > >> > On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko
> > >> > <olekstysh@gmail.com>
> > >> > wrote:
> > >> >>
> > >> >> Hi Bharat
> > >> >>
> > >> >> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil <ghl.bhrt@gmail.com>
> > >> >> wrote:
> > >> >> > Hello Oleksandr,
> > >> >> >
> > >> >> > I have corrected GIC settings but no success.Following line
> > >> >> > disappear
> > >> >> > from
> > >> >> > log.
> > >> >> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
> > >> >> >>> 0x2000
> > >> >> >
> > >> >> > Is anything else which can I try.
> > >> >> >
> > >> >> > I don’t know much about xen internal for ARM architecture. As you
> > >> >> > mentioned,
> > >> >> >>>Wrong GIC settings might lead to that IPIs won't work as
> expected.
> > >> >> >>> And
> > >> >> >>>boot CPU will get stuck waiting for another CPU.
> > >> >> >
> > >> >> > Can you explain it with some boot sequence and relation with IPI?
> > >> >>
> > >> >> Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at
> > >> >> smp_call_function (one CPU didn't receive interrupt from another
> one).
> > >> >> Next patch helped us to fix this issue:
> > >> >> https://patchwork.kernel.org/patch/9163065/
> > >> >>
> > >> >> I assume the SoC you are working with has "arm,gic-400" compatible
> GIC.
> > >> >> Can you take a look at the patch, maybe it is your case too.
> > >> >>
> > >> >> >
> > >> >> > Thanks,
> > >> >> > Bharat
> > >> >> >
> > >> >> >
> > >> >> > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko
> > >> >> > <olekstysh@gmail.com>
> > >> >> > wrote:
> > >> >> >>
> > >> >> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <
> ghl.bhrt@gmail.com>
> > >> >> >> wrote:
> > >> >> >> > Hello Oleksandr,
> > >> >> >> Hi Bharat
> > >> >> >>
> > >> >> >> >
> > >> >> >> > I had removed A72 cluster and tried to boot only two A35 but
> I got
> > >> >> >> > same
> > >> >> >> > error.
> > >> >> >> >
> > >> >> >> > Is anything added or missing in A35 compare to A53?
> > >> >> >> Unfortunately, I don't know.
> > >> >> >>
> > >> >> >> BTW, did you check your GIC settings in the device-tree?
> > >> >> >>
> > >> >> >> >
> > >> >> >> > Regards,
> > >> >> >> > Bharat
> > >> >> >> >
> > >> >> >> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <
> ghl.bhrt@gmail.com>
> > >> >> >> > wrote:
> > >> >> >> >>
> > >> >> >> >> Hello Oleksandr,
> > >> >> >> >> Thank you very much for your input.
> > >> >> >> >>
> > >> >> >> >> Yes. agree. I will check by removing A72 core from DT.
> > >> >> >> >>
> > >> >> >> >> Thanks,
> > >> >> >> >> Bharat
> > >> >> >> >>
> > >> >> >> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
> > >> >> >> >> <olekstysh@gmail.com> wrote:
> > >> >> >> >>>
> > >> >> >> >>> Hi,
> > >> >> >> >>>
> > >> >> >> >>> Not sure that I am a competent person, just my assumptions.
> > >> >> >> >>>
> > >> >> >> >>> CCed ARM guys.
> > >> >> >> >>>
> > >> >> >> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil
> > >> >> >> >>> <ghl.bhrt@gmail.com>
> > >> >> >> >>> wrote:
> > >> >> >> >>> > Hello All
> > >> >> >> >>> >
> > >> >> >> >>> > I am trying to run Xen on new hardware which has two A35
> and
> > >> >> >> >>> > one
> > >> >> >> >>> > A72
> > >> >> >> >>> > core.
> > >> >> >> >>> > Xen booted intially but it hangs at
> > >> >> >> >>> > smp_call_function(setup_virt_paging_one,
> > >> >> >> >>> > (void *)val, 1) function call.
> > >> >> >> >>>
> > >> >> >> >>> It might be a consequence of that CPU cores are different.
> And
> > >> >> >> >>> they
> > >> >> >> >>> might have different set of features, or even settings.
> > >> >> >> >>> And these features/settings the boot CPU has don't
> compatible
> > >> >> >> >>> with
> > >> >> >> >>> other (non-boot) CPUs.
> > >> >> >> >>> Can you try not to bringup A72 core (remove it from DT or
> > >> >> >> >>> another
> > >> >> >> >>> way), leave only two A35 and see what will happen.
> > >> >> >> >>>
> > >> >> >> >>> > Find following log of Xen booting,same set of features.
> > >> >> >> >>> >
> > >> >> >> >>> > - UART enabled -
> > >> >> >> >>> > - CPU 00000000 booting -
> > >> >> >> >>> > - Current EL 00000008 -
> > >> >> >> >>> > - Xen starting at EL2 -
> > >> >> >> >>> > - Zero BSS -
> > >> >> >> >>> > - Setting up control registers -
> > >> >> >> >>> > - Turning on paging -
> > >> >> >> >>> > - Ready -
> > >> >> >> >>> > (XEN) Checking for initrd in /chosen
> > >> >> >> >>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
> > >> >> >> >>> > (XEN)
> > >> >> >> >>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a
> Device
> > >> >> >> >>> > Tree
> > >> >> >> >>> > (XEN)
> > >> >> >> >>> > (XEN) Command line: <NULL>
> > >> >> >> >>> Why? Does your device-tree have bootargs?
> > >> >> >> >>>
> > >> >> >> >>> > (XEN) Placing Xen at 0x00000000bfe00000-
> 0x00000000c0000000
> > >> >> >> >>> > (XEN) Update BOOTMOD_XEN from
> > >> >> >> >>> > 0000000040080000-0000000040194e01
> > >> >> >> >>> > =>
> > >> >> >> >>> > 00000000bfe01
> > >> >> >> >>> > (XEN) Domain heap initialised
> > >> >> >> >>> > (XEN) Booting using Device Tree
> > >> >> >> >>> > (XEN) Platform: Generic System
> > >> >> >> >>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
> > >> >> >> >>> > (XEN) Looking for dtuart at "serial0", options ""
> > >> >> >> >>> > __ __ _ _ _ ___ _
> > >> >> >> >>> > _
> > >> >> >> >>> > _
> > >> >> >> >>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_
> __
> > >> >> >> >>> > _|
> > >> >> >> >>> > |__
> > >> >> >> >>> > | |
> > >> >> >> >>> > ___
> > >> >> >> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __|
> __/ _`
> > >> >> >> >>> > |
> > >> >> >> >>> > '_
> > >> >> >> >>> > \|
> > >> >> >> >>> > |/ _ \
> > >> >> >> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ ||
> (_|
> > >> >> >> >>> > |
> > >> >> >> >>> > |_)
> > >> >> >> >>> > | |
> > >> >> >> >>> > __/
> > >> >> >> >>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
> > >> >> >> >>> > |_|___/\__\__,_|_.__/|_|\___|
> > >> >> >> >>> >
> > >> >> >> >>> > (XEN) Xen version 4.10-unstable (bgohil@)
> > >> >> >> >>> > (aarch64-linux-gnu-gcc
> > >> >> >> >>> > (Ubuntu/Linaro7
> > >> >> >> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
> > >> >> >> >>> > git:9053a74-dirty
> > >> >> >> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0,
> part
> > >> >> >> >>> > 0xd04,
> > >> >> >> >>> > rev
> > >> >> >> >>> > 0x1
> > >> >> >> >>> > (XEN) 64-bit Execution:
> > >> >> >> >>> > (XEN) Processor Features: 0000000000002222
> 0000000000000000
> > >> >> >> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32
> > >> >> >> >>> > EL0:64+32
> > >> >> >> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
> > >> >> >> >>> > (XEN) Debug Features: 0000000010305106 0000000000000000
> > >> >> >> >>> > (XEN) Auxiliary Features: 0000000000000000
> 0000000000000000
> > >> >> >> >>> > (XEN) Memory Model Features: 0000000000101122
> > >> >> >> >>> > 0000000000000000
> > >> >> >> >>> > (XEN) ISA Features: 0000000000011120 0000000000000000
> > >> >> >> >>> > (XEN) 32-bit Execution:
> > >> >> >> >>> > (XEN) Processor Features: 00000131:00011011
> > >> >> >> >>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2
> Jazelle
> > >> >> >> >>> > (XEN) Extensions: GenericTimer Security
> > >> >> >> >>> > (XEN) Debug Features: 03010066
> > >> >> >> >>> > (XEN) Auxiliary Features: 00000000
> > >> >> >> >>> > (XEN) Memory Model Features: 10201105 40000000 01260000
> > >> >> >> >>> > 02102211
> > >> >> >> >>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131
> > >> >> >> >>> > 00011142
> > >> >> >> >>> > 00011121
> > >> >> >> >>> > (XEN) Using PSCI-1.0 for SMP bringup
> > >> >> >> >>> > (XEN) SMP: Allowing 3 CPUs
> > >> >> >> >>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq:
> 13000
> > >> >> >> >>> > KHz
> > >> >> >> >>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000
> > >> >> >> >>> > expected
> > >> >> >> >>> > 0x2000
> > >> >> >> >>> Sounds like GIC settings are not completely correct.
> > >> >> >> >>> Wrong GIC settings might lead to that IPIs won't work as
> > >> >> >> >>> expected.
> > >> >> >> >>> And
> > >> >> >> >>> boot CPU will
> > >> >> >> >>> get stuck waiting for another CPU.
> > >> >> >> >>> Just double check.
> > >> >> >> >>>
> > >> >> >> >>> > (XEN) GICv2 initialization:
> > >> >> >> >>> > (XEN) gic_dist_addr=0000000010510000
> > >> >> >> >>> > (XEN) gic_cpu_addr=0000000010520000
> > >> >> >> >>> > (XEN) gic_hyp_addr=0000000010540000
> > >> >> >> >>> > (XEN) gic_vcpu_addr=0000000010560000
> > >> >> >> >>> > (XEN) gic_maintenance_irq=25
> > >> >> >> >>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
> > >> >> >> >>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > >> >> >> >>> > (XEN) Allocated console ring of 32 KiB.
> > >> >> >> >>> > (XEN) Bringing up CPU1
> > >> >> >> >>> > - CPU 00000001 booting -
> > >> >> >> >>> > - Current EL 00000008 -
> > >> >> >> >>> > - Xen starting at EL2 -
> > >> >> >> >>> > - Setting up control registers -
> > >> >> >> >>> > - Turning on paging -
> > >> >> >> >>> > - Ready -
> > >> >> >> >>> > (XEN) CPU 1 booted.
> > >> >> >> >>> > (XEN) Bringing up CPU2
> > >> >> >> >>> > - CPU 00000200 booting -
> > >> >> >> >>> > - Current EL 00000008 -
> > >> >> >> >>> > - Xen starting at EL2 -
> > >> >> >> >>> > - Setting up control registers -
> > >> >> >> >>> > - Turning on paging -
> > >> >> >> >>> > - Ready -
> > >> >> >> >>> > (XEN) CPU 2 booted.
> > >> >> >> >>> > (XEN) Brought up 3 CPUs
> > >> >> >> >>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> > >> >> >> >>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> > >> >> >> >>> >
> > >> >> >> >>> > Can anyone guide me how to debug this problem or what
> could be
> > >> >> >> >>> > wrong
> > >> >> >> >>> > here?
> > >> >> >> >>> >
> > >> >> >> >>> > It looks, writing into VTCR_EL2 hang the system.
> > >> >> >> >>> >
> > >> >> >> >>> > --
> > >> >> >> >>> > Regards,
> > >> >> >> >>> > Bharat Gohil
> > >> >> >> >>> >
> > >> >> >> >>> >
> > >> >> >> >>> > _______________________________________________
> > >> >> >> >>> > Xen-devel mailing list
> > >> >> >> >>> > Xen-devel@lists.xen.org
> > >> >> >> >>> > https://lists.xen.org/xen-devel
> > >> >> >> >>> >
> > >> >> >> >>>
> > >> >> >> >>> --
> > >> >> >> >>> Regards,
> > >> >> >> >>>
> > >> >> >> >>> Oleksandr Tyshchenko
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >> --
> > >> >> >> >> Regards,
> > >> >> >> >> Bharat Gohil
> > >> >> >> >> Sr.Software Engineer
> > >> >> >> >> bharat.gohil@harman.com
> > >> >> >> >> +919427054633
> > >> >> >> >
> > >> >> >> >
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > --
> > >> >> >> > Regards,
> > >> >> >> > Bharat Gohil
> > >> >> >> > Sr.Software Engineer
> > >> >> >> > bharat.gohil@harman.com
> > >> >> >> > +919427054633
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >> --
> > >> >> >> Regards,
> > >> >> >>
> > >> >> >> Oleksandr Tyshchenko
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > --
> > >> >> > Regards,
> > >> >> > Bharat Gohil
> > >> >> > Sr.Software Engineer
> > >> >> > bharat.gohil@harman.com
> > >> >> > +919427054633
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Regards,
> > >> >>
> > >> >> Oleksandr Tyshchenko
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Regards,
> > >> > Bharat Gohil
> > >> > Sr.Software Engineer
> > >> > bharat.gohil@harman.com
> > >> > +919427054633
> > >>
> > >>
> > >>
> > >> --
> > >> Regards,
> > >>
> > >> Oleksandr Tyshchenko
> > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Bharat Gohil
> > > Sr.Software Engineer
> > > bharat.gohil@harman.com
> > > +919427054633
> >
> >
> >
> > --
> > Regards,
> >
> > Oleksandr Tyshchenko
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 28317 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-22 10:00 ` bharat gohil
@ 2017-09-22 13:43 ` Konrad Rzeszutek Wilk
2017-09-25 8:42 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Konrad Rzeszutek Wilk @ 2017-09-22 13:43 UTC (permalink / raw)
To: bharat gohil
Cc: Oleksandr Tyshchenko, Julien Grall, Stefano Stabellini, Xen Devel
On Fri, Sep 22, 2017 at 03:30:57PM +0530, bharat gohil wrote:
> Hello Wilk,
>
> I had try 'console=hvc0' but no success.
>
> @Oleksandr: At this moment it is difficult to share any file of guest.
> It would be helpful if anyone provide me general technique to debug dom0
> bringup issue.
You can also hit 'Ctrl-a' three times and then 'd' which would give you
the stack trace and EIP of dom0. That should help in figuirng where your
dom0 is stuck.
>
> Thanks,
> Bharat
>
> On Mon, Sep 18, 2017 at 8:16 PM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com> wrote:
>
> > On Fri, Sep 08, 2017 at 10:19:55PM +0300, Oleksandr Tyshchenko wrote:
> > > Hi Bharat
> > >
> > > On Thu, Sep 7, 2017 at 4:30 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> > > > Hello Olensandr,
> > > >
> > > > I able to boot xen and trying to boot dom0 but there are no console
> > log for
> > > > dom0.
> > > >
> > > > following log for xen and it stuck booting dom0.
> > > >
> > > > (XEN) I/O virtualisation disabled
> > > > (XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
> > > > (XEN) alternatives: Patching with alt table 00000000400d2e08 ->
> > > > 00000000400d32dc
> > > > (XEN) *** LOADING DOMAIN 0 ***
> > > > (XEN) Loading kernel from boot module @ 0000000040148158
> > > > (XEN) Allocating 1:1 mappings totalling 128MB for dom0:
> > > > (XEN) BANK[0] 0x00000048000000-0x00000050000000 (128MB)
> > > > (XEN) Grant table range: 0x000000bfe00000-0x000000bfe65000
> > > > (XEN) Loading zImage from 0000000040148158 to
> > > > 0000000048080000-0000000049480000
> > > > (XEN) Allocating PPI 16 for event channel interrupt
> > > > (XEN) Loading dom0 DTB to 0x000000004fe00000-0x000000004fe0f31e
> > > > (XEN) Scrubbing Free RAM on 1 nodes using 3 CPUs
> > > > (XEN) ......done.
> > > > (XEN) Initial low memory virq threshold set at 0x4000 pages.
> > > > (XEN) Std. Loglevel: All
> > > > (XEN) Guest Loglevel: All
> > > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> > input to
> > > > Xen)
> > > > (XEN) Freed 272kB init memory.
> > > >
> > > > I have done all the xen configuration in linux kernel 4.9. This kernel
> > > > booting fine without xen.
> > > >
> > > > following are the DTB changes,
> > > >
> > > > chosen {
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > > bootargs = "console=dtuart dtuart=serial0 dom0_mem=128M";
> > > > stdout-path = "serial0";
> > > > module: module@0 {
> > > > compatible = "xen,linux-zimage", "xen,multiboot-module";
> > > > reg = <0x40148158 0x1400000>;
> > > > bootargs = "console=hvc0,921600n8 earlyprintk=xen debug
> >
> > It should be just 'console=hvc0', not 'console=hvc0,921600n8'
> >
> > > > ignore_loglevel rw root=/dev/mmcblk0p7";
> > > > };
> > > >
> > > > };
> > > >
> > > > Can you tell me how to debug dom0 booting or anything which i can
> > check?
> > >
> > > Don't now much about "debug dom0 booting", I leave it for competent
> > people.
> > >
> > > Looks weird, even with earlyprintk no logs.
> > > Do you have DEBUG_LL and all related options enabled in your dom0 kernel
> > config?
> > >
> > > 1. Check that following options are enabled in your kernel config file:
> > >
> > > CONFIG_HVC_XEN=y
> > > CONFIG_HVC_XEN_FRONTEND=y
> > >
> > > 2. Check that dom0 kernel doesn't disable clock for console.
> > >
> > > BTW, could you post full Xen log, kernel config and device-tree you are
> > using?
> > > If you have some changes on top of Xen, post them too.
> > > These may help people to identify what is wrong.
> > >
> > > >
> > > >
> > > > Thanks,
> > > > Bharat
> > > >
> > > > On Wed, Sep 6, 2017 at 3:49 PM, Oleksandr Tyshchenko <
> > olekstysh@gmail.com>
> > > > wrote:
> > > >>
> > > >> Hi Bharat
> > > >>
> > > >> On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil <ghl.bhrt@gmail.com>
> > wrote:
> > > >> > Hello Oleksandr,
> > > >> >
> > > >> > Thank you very much.It resolved my issue.
> > > >> Sounds great!
> > > >>
> > > >> >
> > > >> > Thanks,
> > > >> > Bharat
> > > >> >
> > > >> > On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko
> > > >> > <olekstysh@gmail.com>
> > > >> > wrote:
> > > >> >>
> > > >> >> Hi Bharat
> > > >> >>
> > > >> >> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil <ghl.bhrt@gmail.com>
> > > >> >> wrote:
> > > >> >> > Hello Oleksandr,
> > > >> >> >
> > > >> >> > I have corrected GIC settings but no success.Following line
> > > >> >> > disappear
> > > >> >> > from
> > > >> >> > log.
> > > >> >> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
> > > >> >> >>> 0x2000
> > > >> >> >
> > > >> >> > Is anything else which can I try.
> > > >> >> >
> > > >> >> > I don’t know much about xen internal for ARM architecture. As you
> > > >> >> > mentioned,
> > > >> >> >>>Wrong GIC settings might lead to that IPIs won't work as
> > expected.
> > > >> >> >>> And
> > > >> >> >>>boot CPU will get stuck waiting for another CPU.
> > > >> >> >
> > > >> >> > Can you explain it with some boot sequence and relation with IPI?
> > > >> >>
> > > >> >> Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at
> > > >> >> smp_call_function (one CPU didn't receive interrupt from another
> > one).
> > > >> >> Next patch helped us to fix this issue:
> > > >> >> https://patchwork.kernel.org/patch/9163065/
> > > >> >>
> > > >> >> I assume the SoC you are working with has "arm,gic-400" compatible
> > GIC.
> > > >> >> Can you take a look at the patch, maybe it is your case too.
> > > >> >>
> > > >> >> >
> > > >> >> > Thanks,
> > > >> >> > Bharat
> > > >> >> >
> > > >> >> >
> > > >> >> > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko
> > > >> >> > <olekstysh@gmail.com>
> > > >> >> > wrote:
> > > >> >> >>
> > > >> >> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <
> > ghl.bhrt@gmail.com>
> > > >> >> >> wrote:
> > > >> >> >> > Hello Oleksandr,
> > > >> >> >> Hi Bharat
> > > >> >> >>
> > > >> >> >> >
> > > >> >> >> > I had removed A72 cluster and tried to boot only two A35 but
> > I got
> > > >> >> >> > same
> > > >> >> >> > error.
> > > >> >> >> >
> > > >> >> >> > Is anything added or missing in A35 compare to A53?
> > > >> >> >> Unfortunately, I don't know.
> > > >> >> >>
> > > >> >> >> BTW, did you check your GIC settings in the device-tree?
> > > >> >> >>
> > > >> >> >> >
> > > >> >> >> > Regards,
> > > >> >> >> > Bharat
> > > >> >> >> >
> > > >> >> >> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <
> > ghl.bhrt@gmail.com>
> > > >> >> >> > wrote:
> > > >> >> >> >>
> > > >> >> >> >> Hello Oleksandr,
> > > >> >> >> >> Thank you very much for your input.
> > > >> >> >> >>
> > > >> >> >> >> Yes. agree. I will check by removing A72 core from DT.
> > > >> >> >> >>
> > > >> >> >> >> Thanks,
> > > >> >> >> >> Bharat
> > > >> >> >> >>
> > > >> >> >> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
> > > >> >> >> >> <olekstysh@gmail.com> wrote:
> > > >> >> >> >>>
> > > >> >> >> >>> Hi,
> > > >> >> >> >>>
> > > >> >> >> >>> Not sure that I am a competent person, just my assumptions.
> > > >> >> >> >>>
> > > >> >> >> >>> CCed ARM guys.
> > > >> >> >> >>>
> > > >> >> >> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil
> > > >> >> >> >>> <ghl.bhrt@gmail.com>
> > > >> >> >> >>> wrote:
> > > >> >> >> >>> > Hello All
> > > >> >> >> >>> >
> > > >> >> >> >>> > I am trying to run Xen on new hardware which has two A35
> > and
> > > >> >> >> >>> > one
> > > >> >> >> >>> > A72
> > > >> >> >> >>> > core.
> > > >> >> >> >>> > Xen booted intially but it hangs at
> > > >> >> >> >>> > smp_call_function(setup_virt_paging_one,
> > > >> >> >> >>> > (void *)val, 1) function call.
> > > >> >> >> >>>
> > > >> >> >> >>> It might be a consequence of that CPU cores are different.
> > And
> > > >> >> >> >>> they
> > > >> >> >> >>> might have different set of features, or even settings.
> > > >> >> >> >>> And these features/settings the boot CPU has don't
> > compatible
> > > >> >> >> >>> with
> > > >> >> >> >>> other (non-boot) CPUs.
> > > >> >> >> >>> Can you try not to bringup A72 core (remove it from DT or
> > > >> >> >> >>> another
> > > >> >> >> >>> way), leave only two A35 and see what will happen.
> > > >> >> >> >>>
> > > >> >> >> >>> > Find following log of Xen booting,same set of features.
> > > >> >> >> >>> >
> > > >> >> >> >>> > - UART enabled -
> > > >> >> >> >>> > - CPU 00000000 booting -
> > > >> >> >> >>> > - Current EL 00000008 -
> > > >> >> >> >>> > - Xen starting at EL2 -
> > > >> >> >> >>> > - Zero BSS -
> > > >> >> >> >>> > - Setting up control registers -
> > > >> >> >> >>> > - Turning on paging -
> > > >> >> >> >>> > - Ready -
> > > >> >> >> >>> > (XEN) Checking for initrd in /chosen
> > > >> >> >> >>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
> > > >> >> >> >>> > (XEN)
> > > >> >> >> >>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a
> > Device
> > > >> >> >> >>> > Tree
> > > >> >> >> >>> > (XEN)
> > > >> >> >> >>> > (XEN) Command line: <NULL>
> > > >> >> >> >>> Why? Does your device-tree have bootargs?
> > > >> >> >> >>>
> > > >> >> >> >>> > (XEN) Placing Xen at 0x00000000bfe00000-
> > 0x00000000c0000000
> > > >> >> >> >>> > (XEN) Update BOOTMOD_XEN from
> > > >> >> >> >>> > 0000000040080000-0000000040194e01
> > > >> >> >> >>> > =>
> > > >> >> >> >>> > 00000000bfe01
> > > >> >> >> >>> > (XEN) Domain heap initialised
> > > >> >> >> >>> > (XEN) Booting using Device Tree
> > > >> >> >> >>> > (XEN) Platform: Generic System
> > > >> >> >> >>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
> > > >> >> >> >>> > (XEN) Looking for dtuart at "serial0", options ""
> > > >> >> >> >>> > __ __ _ _ _ ___ _
> > > >> >> >> >>> > _
> > > >> >> >> >>> > _
> > > >> >> >> >>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __ ___| |_
> > __
> > > >> >> >> >>> > _|
> > > >> >> >> >>> > |__
> > > >> >> >> >>> > | |
> > > >> >> >> >>> > ___
> > > >> >> >> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __|
> > __/ _`
> > > >> >> >> >>> > |
> > > >> >> >> >>> > '_
> > > >> >> >> >>> > \|
> > > >> >> >> >>> > |/ _ \
> > > >> >> >> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ ||
> > (_|
> > > >> >> >> >>> > |
> > > >> >> >> >>> > |_)
> > > >> >> >> >>> > | |
> > > >> >> >> >>> > __/
> > > >> >> >> >>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
> > > >> >> >> >>> > |_|___/\__\__,_|_.__/|_|\___|
> > > >> >> >> >>> >
> > > >> >> >> >>> > (XEN) Xen version 4.10-unstable (bgohil@)
> > > >> >> >> >>> > (aarch64-linux-gnu-gcc
> > > >> >> >> >>> > (Ubuntu/Linaro7
> > > >> >> >> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
> > > >> >> >> >>> > git:9053a74-dirty
> > > >> >> >> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0,
> > part
> > > >> >> >> >>> > 0xd04,
> > > >> >> >> >>> > rev
> > > >> >> >> >>> > 0x1
> > > >> >> >> >>> > (XEN) 64-bit Execution:
> > > >> >> >> >>> > (XEN) Processor Features: 0000000000002222
> > 0000000000000000
> > > >> >> >> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32
> > > >> >> >> >>> > EL0:64+32
> > > >> >> >> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
> > > >> >> >> >>> > (XEN) Debug Features: 0000000010305106 0000000000000000
> > > >> >> >> >>> > (XEN) Auxiliary Features: 0000000000000000
> > 0000000000000000
> > > >> >> >> >>> > (XEN) Memory Model Features: 0000000000101122
> > > >> >> >> >>> > 0000000000000000
> > > >> >> >> >>> > (XEN) ISA Features: 0000000000011120 0000000000000000
> > > >> >> >> >>> > (XEN) 32-bit Execution:
> > > >> >> >> >>> > (XEN) Processor Features: 00000131:00011011
> > > >> >> >> >>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2
> > Jazelle
> > > >> >> >> >>> > (XEN) Extensions: GenericTimer Security
> > > >> >> >> >>> > (XEN) Debug Features: 03010066
> > > >> >> >> >>> > (XEN) Auxiliary Features: 00000000
> > > >> >> >> >>> > (XEN) Memory Model Features: 10201105 40000000 01260000
> > > >> >> >> >>> > 02102211
> > > >> >> >> >>> > (XEN) ISA Features: 02101110 13112111 21232042 01112131
> > > >> >> >> >>> > 00011142
> > > >> >> >> >>> > 00011121
> > > >> >> >> >>> > (XEN) Using PSCI-1.0 for SMP bringup
> > > >> >> >> >>> > (XEN) SMP: Allowing 3 CPUs
> > > >> >> >> >>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq:
> > 13000
> > > >> >> >> >>> > KHz
> > > >> >> >> >>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000
> > > >> >> >> >>> > expected
> > > >> >> >> >>> > 0x2000
> > > >> >> >> >>> Sounds like GIC settings are not completely correct.
> > > >> >> >> >>> Wrong GIC settings might lead to that IPIs won't work as
> > > >> >> >> >>> expected.
> > > >> >> >> >>> And
> > > >> >> >> >>> boot CPU will
> > > >> >> >> >>> get stuck waiting for another CPU.
> > > >> >> >> >>> Just double check.
> > > >> >> >> >>>
> > > >> >> >> >>> > (XEN) GICv2 initialization:
> > > >> >> >> >>> > (XEN) gic_dist_addr=0000000010510000
> > > >> >> >> >>> > (XEN) gic_cpu_addr=0000000010520000
> > > >> >> >> >>> > (XEN) gic_hyp_addr=0000000010540000
> > > >> >> >> >>> > (XEN) gic_vcpu_addr=0000000010560000
> > > >> >> >> >>> > (XEN) gic_maintenance_irq=25
> > > >> >> >> >>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
> > > >> >> >> >>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > > >> >> >> >>> > (XEN) Allocated console ring of 32 KiB.
> > > >> >> >> >>> > (XEN) Bringing up CPU1
> > > >> >> >> >>> > - CPU 00000001 booting -
> > > >> >> >> >>> > - Current EL 00000008 -
> > > >> >> >> >>> > - Xen starting at EL2 -
> > > >> >> >> >>> > - Setting up control registers -
> > > >> >> >> >>> > - Turning on paging -
> > > >> >> >> >>> > - Ready -
> > > >> >> >> >>> > (XEN) CPU 1 booted.
> > > >> >> >> >>> > (XEN) Bringing up CPU2
> > > >> >> >> >>> > - CPU 00000200 booting -
> > > >> >> >> >>> > - Current EL 00000008 -
> > > >> >> >> >>> > - Xen starting at EL2 -
> > > >> >> >> >>> > - Setting up control registers -
> > > >> >> >> >>> > - Turning on paging -
> > > >> >> >> >>> > - Ready -
> > > >> >> >> >>> > (XEN) CPU 2 booted.
> > > >> >> >> >>> > (XEN) Brought up 3 CPUs
> > > >> >> >> >>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> > > >> >> >> >>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> > > >> >> >> >>> >
> > > >> >> >> >>> > Can anyone guide me how to debug this problem or what
> > could be
> > > >> >> >> >>> > wrong
> > > >> >> >> >>> > here?
> > > >> >> >> >>> >
> > > >> >> >> >>> > It looks, writing into VTCR_EL2 hang the system.
> > > >> >> >> >>> >
> > > >> >> >> >>> > --
> > > >> >> >> >>> > Regards,
> > > >> >> >> >>> > Bharat Gohil
> > > >> >> >> >>> >
> > > >> >> >> >>> >
> > > >> >> >> >>> > _______________________________________________
> > > >> >> >> >>> > Xen-devel mailing list
> > > >> >> >> >>> > Xen-devel@lists.xen.org
> > > >> >> >> >>> > https://lists.xen.org/xen-devel
> > > >> >> >> >>> >
> > > >> >> >> >>>
> > > >> >> >> >>> --
> > > >> >> >> >>> Regards,
> > > >> >> >> >>>
> > > >> >> >> >>> Oleksandr Tyshchenko
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >> --
> > > >> >> >> >> Regards,
> > > >> >> >> >> Bharat Gohil
> > > >> >> >> >> Sr.Software Engineer
> > > >> >> >> >> bharat.gohil@harman.com
> > > >> >> >> >> +919427054633
> > > >> >> >> >
> > > >> >> >> >
> > > >> >> >> >
> > > >> >> >> >
> > > >> >> >> > --
> > > >> >> >> > Regards,
> > > >> >> >> > Bharat Gohil
> > > >> >> >> > Sr.Software Engineer
> > > >> >> >> > bharat.gohil@harman.com
> > > >> >> >> > +919427054633
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>
> > > >> >> >> --
> > > >> >> >> Regards,
> > > >> >> >>
> > > >> >> >> Oleksandr Tyshchenko
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> > --
> > > >> >> > Regards,
> > > >> >> > Bharat Gohil
> > > >> >> > Sr.Software Engineer
> > > >> >> > bharat.gohil@harman.com
> > > >> >> > +919427054633
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> Regards,
> > > >> >>
> > > >> >> Oleksandr Tyshchenko
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Regards,
> > > >> > Bharat Gohil
> > > >> > Sr.Software Engineer
> > > >> > bharat.gohil@harman.com
> > > >> > +919427054633
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Regards,
> > > >>
> > > >> Oleksandr Tyshchenko
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Bharat Gohil
> > > > Sr.Software Engineer
> > > > bharat.gohil@harman.com
> > > > +919427054633
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Oleksandr Tyshchenko
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > https://lists.xen.org/xen-devel
> >
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com
> +919427054633
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-22 13:43 ` Konrad Rzeszutek Wilk
@ 2017-09-25 8:42 ` bharat gohil
2017-09-25 12:15 ` Andrii Anisov
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-09-25 8:42 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Oleksandr Tyshchenko, Julien Grall, Stefano Stabellini, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 18678 bytes --]
Hello Wilk,
I had try Ctrl+a three times and 'd' but no dump on the serial console.
Thanks,
Bharat
On Fri, Sep 22, 2017 at 7:13 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:
> On Fri, Sep 22, 2017 at 03:30:57PM +0530, bharat gohil wrote:
> > Hello Wilk,
> >
> > I had try 'console=hvc0' but no success.
> >
> > @Oleksandr: At this moment it is difficult to share any file of guest.
> > It would be helpful if anyone provide me general technique to debug dom0
> > bringup issue.
>
> You can also hit 'Ctrl-a' three times and then 'd' which would give you
> the stack trace and EIP of dom0. That should help in figuirng where your
> dom0 is stuck.
>
> >
> > Thanks,
> > Bharat
> >
> > On Mon, Sep 18, 2017 at 8:16 PM, Konrad Rzeszutek Wilk <
> > konrad.wilk@oracle.com> wrote:
> >
> > > On Fri, Sep 08, 2017 at 10:19:55PM +0300, Oleksandr Tyshchenko wrote:
> > > > Hi Bharat
> > > >
> > > > On Thu, Sep 7, 2017 at 4:30 PM, bharat gohil <ghl.bhrt@gmail.com>
> wrote:
> > > > > Hello Olensandr,
> > > > >
> > > > > I able to boot xen and trying to boot dom0 but there are no console
> > > log for
> > > > > dom0.
> > > > >
> > > > > following log for xen and it stuck booting dom0.
> > > > >
> > > > > (XEN) I/O virtualisation disabled
> > > > > (XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
> > > > > (XEN) alternatives: Patching with alt table 00000000400d2e08 ->
> > > > > 00000000400d32dc
> > > > > (XEN) *** LOADING DOMAIN 0 ***
> > > > > (XEN) Loading kernel from boot module @ 0000000040148158
> > > > > (XEN) Allocating 1:1 mappings totalling 128MB for dom0:
> > > > > (XEN) BANK[0] 0x00000048000000-0x00000050000000 (128MB)
> > > > > (XEN) Grant table range: 0x000000bfe00000-0x000000bfe65000
> > > > > (XEN) Loading zImage from 0000000040148158 to
> > > > > 0000000048080000-0000000049480000
> > > > > (XEN) Allocating PPI 16 for event channel interrupt
> > > > > (XEN) Loading dom0 DTB to 0x000000004fe00000-0x000000004fe0f31e
> > > > > (XEN) Scrubbing Free RAM on 1 nodes using 3 CPUs
> > > > > (XEN) ......done.
> > > > > (XEN) Initial low memory virq threshold set at 0x4000 pages.
> > > > > (XEN) Std. Loglevel: All
> > > > > (XEN) Guest Loglevel: All
> > > > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> > > input to
> > > > > Xen)
> > > > > (XEN) Freed 272kB init memory.
> > > > >
> > > > > I have done all the xen configuration in linux kernel 4.9. This
> kernel
> > > > > booting fine without xen.
> > > > >
> > > > > following are the DTB changes,
> > > > >
> > > > > chosen {
> > > > > #address-cells = <1>;
> > > > > #size-cells = <1>;
> > > > > bootargs = "console=dtuart dtuart=serial0 dom0_mem=128M";
> > > > > stdout-path = "serial0";
> > > > > module: module@0 {
> > > > > compatible = "xen,linux-zimage",
> "xen,multiboot-module";
> > > > > reg = <0x40148158 0x1400000>;
> > > > > bootargs = "console=hvc0,921600n8 earlyprintk=xen debug
> > >
> > > It should be just 'console=hvc0', not 'console=hvc0,921600n8'
> > >
> > > > > ignore_loglevel rw root=/dev/mmcblk0p7";
> > > > > };
> > > > >
> > > > > };
> > > > >
> > > > > Can you tell me how to debug dom0 booting or anything which i can
> > > check?
> > > >
> > > > Don't now much about "debug dom0 booting", I leave it for competent
> > > people.
> > > >
> > > > Looks weird, even with earlyprintk no logs.
> > > > Do you have DEBUG_LL and all related options enabled in your dom0
> kernel
> > > config?
> > > >
> > > > 1. Check that following options are enabled in your kernel config
> file:
> > > >
> > > > CONFIG_HVC_XEN=y
> > > > CONFIG_HVC_XEN_FRONTEND=y
> > > >
> > > > 2. Check that dom0 kernel doesn't disable clock for console.
> > > >
> > > > BTW, could you post full Xen log, kernel config and device-tree you
> are
> > > using?
> > > > If you have some changes on top of Xen, post them too.
> > > > These may help people to identify what is wrong.
> > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Bharat
> > > > >
> > > > > On Wed, Sep 6, 2017 at 3:49 PM, Oleksandr Tyshchenko <
> > > olekstysh@gmail.com>
> > > > > wrote:
> > > > >>
> > > > >> Hi Bharat
> > > > >>
> > > > >> On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil <ghl.bhrt@gmail.com
> >
> > > wrote:
> > > > >> > Hello Oleksandr,
> > > > >> >
> > > > >> > Thank you very much.It resolved my issue.
> > > > >> Sounds great!
> > > > >>
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Bharat
> > > > >> >
> > > > >> > On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko
> > > > >> > <olekstysh@gmail.com>
> > > > >> > wrote:
> > > > >> >>
> > > > >> >> Hi Bharat
> > > > >> >>
> > > > >> >> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil <
> ghl.bhrt@gmail.com>
> > > > >> >> wrote:
> > > > >> >> > Hello Oleksandr,
> > > > >> >> >
> > > > >> >> > I have corrected GIC settings but no success.Following line
> > > > >> >> > disappear
> > > > >> >> > from
> > > > >> >> > log.
> > > > >> >> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000
> expected
> > > > >> >> >>> 0x2000
> > > > >> >> >
> > > > >> >> > Is anything else which can I try.
> > > > >> >> >
> > > > >> >> > I don’t know much about xen internal for ARM architecture.
> As you
> > > > >> >> > mentioned,
> > > > >> >> >>>Wrong GIC settings might lead to that IPIs won't work as
> > > expected.
> > > > >> >> >>> And
> > > > >> >> >>>boot CPU will get stuck waiting for another CPU.
> > > > >> >> >
> > > > >> >> > Can you explain it with some boot sequence and relation with
> IPI?
> > > > >> >>
> > > > >> >> Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung
> at
> > > > >> >> smp_call_function (one CPU didn't receive interrupt from
> another
> > > one).
> > > > >> >> Next patch helped us to fix this issue:
> > > > >> >> https://patchwork.kernel.org/patch/9163065/
> > > > >> >>
> > > > >> >> I assume the SoC you are working with has "arm,gic-400"
> compatible
> > > GIC.
> > > > >> >> Can you take a look at the patch, maybe it is your case too.
> > > > >> >>
> > > > >> >> >
> > > > >> >> > Thanks,
> > > > >> >> > Bharat
> > > > >> >> >
> > > > >> >> >
> > > > >> >> > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko
> > > > >> >> > <olekstysh@gmail.com>
> > > > >> >> > wrote:
> > > > >> >> >>
> > > > >> >> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil <
> > > ghl.bhrt@gmail.com>
> > > > >> >> >> wrote:
> > > > >> >> >> > Hello Oleksandr,
> > > > >> >> >> Hi Bharat
> > > > >> >> >>
> > > > >> >> >> >
> > > > >> >> >> > I had removed A72 cluster and tried to boot only two A35
> but
> > > I got
> > > > >> >> >> > same
> > > > >> >> >> > error.
> > > > >> >> >> >
> > > > >> >> >> > Is anything added or missing in A35 compare to A53?
> > > > >> >> >> Unfortunately, I don't know.
> > > > >> >> >>
> > > > >> >> >> BTW, did you check your GIC settings in the device-tree?
> > > > >> >> >>
> > > > >> >> >> >
> > > > >> >> >> > Regards,
> > > > >> >> >> > Bharat
> > > > >> >> >> >
> > > > >> >> >> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil <
> > > ghl.bhrt@gmail.com>
> > > > >> >> >> > wrote:
> > > > >> >> >> >>
> > > > >> >> >> >> Hello Oleksandr,
> > > > >> >> >> >> Thank you very much for your input.
> > > > >> >> >> >>
> > > > >> >> >> >> Yes. agree. I will check by removing A72 core from DT.
> > > > >> >> >> >>
> > > > >> >> >> >> Thanks,
> > > > >> >> >> >> Bharat
> > > > >> >> >> >>
> > > > >> >> >> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
> > > > >> >> >> >> <olekstysh@gmail.com> wrote:
> > > > >> >> >> >>>
> > > > >> >> >> >>> Hi,
> > > > >> >> >> >>>
> > > > >> >> >> >>> Not sure that I am a competent person, just my
> assumptions.
> > > > >> >> >> >>>
> > > > >> >> >> >>> CCed ARM guys.
> > > > >> >> >> >>>
> > > > >> >> >> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil
> > > > >> >> >> >>> <ghl.bhrt@gmail.com>
> > > > >> >> >> >>> wrote:
> > > > >> >> >> >>> > Hello All
> > > > >> >> >> >>> >
> > > > >> >> >> >>> > I am trying to run Xen on new hardware which has two
> A35
> > > and
> > > > >> >> >> >>> > one
> > > > >> >> >> >>> > A72
> > > > >> >> >> >>> > core.
> > > > >> >> >> >>> > Xen booted intially but it hangs at
> > > > >> >> >> >>> > smp_call_function(setup_virt_paging_one,
> > > > >> >> >> >>> > (void *)val, 1) function call.
> > > > >> >> >> >>>
> > > > >> >> >> >>> It might be a consequence of that CPU cores are
> different.
> > > And
> > > > >> >> >> >>> they
> > > > >> >> >> >>> might have different set of features, or even settings.
> > > > >> >> >> >>> And these features/settings the boot CPU has don't
> > > compatible
> > > > >> >> >> >>> with
> > > > >> >> >> >>> other (non-boot) CPUs.
> > > > >> >> >> >>> Can you try not to bringup A72 core (remove it from DT
> or
> > > > >> >> >> >>> another
> > > > >> >> >> >>> way), leave only two A35 and see what will happen.
> > > > >> >> >> >>>
> > > > >> >> >> >>> > Find following log of Xen booting,same set of
> features.
> > > > >> >> >> >>> >
> > > > >> >> >> >>> > - UART enabled -
> > > > >> >> >> >>> > - CPU 00000000 booting -
> > > > >> >> >> >>> > - Current EL 00000008 -
> > > > >> >> >> >>> > - Xen starting at EL2 -
> > > > >> >> >> >>> > - Zero BSS -
> > > > >> >> >> >>> > - Setting up control registers -
> > > > >> >> >> >>> > - Turning on paging -
> > > > >> >> >> >>> > - Ready -
> > > > >> >> >> >>> > (XEN) Checking for initrd in /chosen
> > > > >> >> >> >>> > (XEN) RAM: 0000000040000000 - 00000000bfffffff
> > > > >> >> >> >>> > (XEN)
> > > > >> >> >> >>> > (XEN) MODULE[0]: 0000000044000000 - 000000004400fd5a
> > > Device
> > > > >> >> >> >>> > Tree
> > > > >> >> >> >>> > (XEN)
> > > > >> >> >> >>> > (XEN) Command line: <NULL>
> > > > >> >> >> >>> Why? Does your device-tree have bootargs?
> > > > >> >> >> >>>
> > > > >> >> >> >>> > (XEN) Placing Xen at 0x00000000bfe00000-
> > > 0x00000000c0000000
> > > > >> >> >> >>> > (XEN) Update BOOTMOD_XEN from
> > > > >> >> >> >>> > 0000000040080000-0000000040194e01
> > > > >> >> >> >>> > =>
> > > > >> >> >> >>> > 00000000bfe01
> > > > >> >> >> >>> > (XEN) Domain heap initialised
> > > > >> >> >> >>> > (XEN) Booting using Device Tree
> > > > >> >> >> >>> > (XEN) Platform: Generic System
> > > > >> >> >> >>> > (XEN) Taking dtuart configuration from
> /chosen/stdout-path
> > > > >> >> >> >>> > (XEN) Looking for dtuart at "serial0", options ""
> > > > >> >> >> >>> > __ __ _ _ _ ___
> _
> > > > >> >> >> >>> > _
> > > > >> >> >> >>> > _
> > > > >> >> >> >>> > \ \/ /___ _ __ | || | / |/ _ \ _ _ _ __
> ___| |_
> > > __
> > > > >> >> >> >>> > _|
> > > > >> >> >> >>> > |__
> > > > >> >> >> >>> > | |
> > > > >> >> >> >>> > ___
> > > > >> >> >> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __|
> > > __/ _`
> > > > >> >> >> >>> > |
> > > > >> >> >> >>> > '_
> > > > >> >> >> >>> > \|
> > > > >> >> >> >>> > |/ _ \
> > > > >> >> >> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__
> \ ||
> > > (_|
> > > > >> >> >> >>> > |
> > > > >> >> >> >>> > |_)
> > > > >> >> >> >>> > | |
> > > > >> >> >> >>> > __/
> > > > >> >> >> >>> > /_/\_\___|_| |_| |_|(_)_|\___/ \__,_|_|
> > > > >> >> >> >>> > |_|___/\__\__,_|_.__/|_|\___|
> > > > >> >> >> >>> >
> > > > >> >> >> >>> > (XEN) Xen version 4.10-unstable (bgohil@)
> > > > >> >> >> >>> > (aarch64-linux-gnu-gcc
> > > > >> >> >> >>> > (Ubuntu/Linaro7
> > > > >> >> >> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
> > > > >> >> >> >>> > git:9053a74-dirty
> > > > >> >> >> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant:
> 0x0,
> > > part
> > > > >> >> >> >>> > 0xd04,
> > > > >> >> >> >>> > rev
> > > > >> >> >> >>> > 0x1
> > > > >> >> >> >>> > (XEN) 64-bit Execution:
> > > > >> >> >> >>> > (XEN) Processor Features: 0000000000002222
> > > 0000000000000000
> > > > >> >> >> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32
> EL1:64+32
> > > > >> >> >> >>> > EL0:64+32
> > > > >> >> >> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
> > > > >> >> >> >>> > (XEN) Debug Features: 0000000010305106
> 0000000000000000
> > > > >> >> >> >>> > (XEN) Auxiliary Features: 0000000000000000
> > > 0000000000000000
> > > > >> >> >> >>> > (XEN) Memory Model Features: 0000000000101122
> > > > >> >> >> >>> > 0000000000000000
> > > > >> >> >> >>> > (XEN) ISA Features: 0000000000011120
> 0000000000000000
> > > > >> >> >> >>> > (XEN) 32-bit Execution:
> > > > >> >> >> >>> > (XEN) Processor Features: 00000131:00011011
> > > > >> >> >> >>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2
> > > Jazelle
> > > > >> >> >> >>> > (XEN) Extensions: GenericTimer Security
> > > > >> >> >> >>> > (XEN) Debug Features: 03010066
> > > > >> >> >> >>> > (XEN) Auxiliary Features: 00000000
> > > > >> >> >> >>> > (XEN) Memory Model Features: 10201105 40000000
> 01260000
> > > > >> >> >> >>> > 02102211
> > > > >> >> >> >>> > (XEN) ISA Features: 02101110 13112111 21232042
> 01112131
> > > > >> >> >> >>> > 00011142
> > > > >> >> >> >>> > 00011121
> > > > >> >> >> >>> > (XEN) Using PSCI-1.0 for SMP bringup
> > > > >> >> >> >>> > (XEN) SMP: Allowing 3 CPUs
> > > > >> >> >> >>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq:
> > > 13000
> > > > >> >> >> >>> > KHz
> > > > >> >> >> >>> > (XEN) GICv2: WARNING: The GICC size is too small:
> 0x1000
> > > > >> >> >> >>> > expected
> > > > >> >> >> >>> > 0x2000
> > > > >> >> >> >>> Sounds like GIC settings are not completely correct.
> > > > >> >> >> >>> Wrong GIC settings might lead to that IPIs won't work as
> > > > >> >> >> >>> expected.
> > > > >> >> >> >>> And
> > > > >> >> >> >>> boot CPU will
> > > > >> >> >> >>> get stuck waiting for another CPU.
> > > > >> >> >> >>> Just double check.
> > > > >> >> >> >>>
> > > > >> >> >> >>> > (XEN) GICv2 initialization:
> > > > >> >> >> >>> > (XEN) gic_dist_addr=0000000010510000
> > > > >> >> >> >>> > (XEN) gic_cpu_addr=0000000010520000
> > > > >> >> >> >>> > (XEN) gic_hyp_addr=0000000010540000
> > > > >> >> >> >>> > (XEN) gic_vcpu_addr=0000000010560000
> > > > >> >> >> >>> > (XEN) gic_maintenance_irq=25
> > > > >> >> >> >>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
> > > > >> >> >> >>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > > > >> >> >> >>> > (XEN) Allocated console ring of 32 KiB.
> > > > >> >> >> >>> > (XEN) Bringing up CPU1
> > > > >> >> >> >>> > - CPU 00000001 booting -
> > > > >> >> >> >>> > - Current EL 00000008 -
> > > > >> >> >> >>> > - Xen starting at EL2 -
> > > > >> >> >> >>> > - Setting up control registers -
> > > > >> >> >> >>> > - Turning on paging -
> > > > >> >> >> >>> > - Ready -
> > > > >> >> >> >>> > (XEN) CPU 1 booted.
> > > > >> >> >> >>> > (XEN) Bringing up CPU2
> > > > >> >> >> >>> > - CPU 00000200 booting -
> > > > >> >> >> >>> > - Current EL 00000008 -
> > > > >> >> >> >>> > - Xen starting at EL2 -
> > > > >> >> >> >>> > - Setting up control registers -
> > > > >> >> >> >>> > - Turning on paging -
> > > > >> >> >> >>> > - Ready -
> > > > >> >> >> >>> > (XEN) CPU 2 booted.
> > > > >> >> >> >>> > (XEN) Brought up 3 CPUs
> > > > >> >> >> >>> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> > > > >> >> >> >>> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> > > > >> >> >> >>> >
> > > > >> >> >> >>> > Can anyone guide me how to debug this problem or what
> > > could be
> > > > >> >> >> >>> > wrong
> > > > >> >> >> >>> > here?
> > > > >> >> >> >>> >
> > > > >> >> >> >>> > It looks, writing into VTCR_EL2 hang the system.
> > > > >> >> >> >>> >
> > > > >> >> >> >>> > --
> > > > >> >> >> >>> > Regards,
> > > > >> >> >> >>> > Bharat Gohil
> > > > >> >> >> >>> >
> > > > >> >> >> >>> >
> > > > >> >> >> >>> > _______________________________________________
> > > > >> >> >> >>> > Xen-devel mailing list
> > > > >> >> >> >>> > Xen-devel@lists.xen.org
> > > > >> >> >> >>> > https://lists.xen.org/xen-devel
> > > > >> >> >> >>> >
> > > > >> >> >> >>>
> > > > >> >> >> >>> --
> > > > >> >> >> >>> Regards,
> > > > >> >> >> >>>
> > > > >> >> >> >>> Oleksandr Tyshchenko
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >> --
> > > > >> >> >> >> Regards,
> > > > >> >> >> >> Bharat Gohil
> > > > >> >> >> >> Sr.Software Engineer
> > > > >> >> >> >> bharat.gohil@harman.com
> > > > >> >> >> >> +919427054633
> > > > >> >> >> >
> > > > >> >> >> >
> > > > >> >> >> >
> > > > >> >> >> >
> > > > >> >> >> > --
> > > > >> >> >> > Regards,
> > > > >> >> >> > Bharat Gohil
> > > > >> >> >> > Sr.Software Engineer
> > > > >> >> >> > bharat.gohil@harman.com
> > > > >> >> >> > +919427054633
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >> --
> > > > >> >> >> Regards,
> > > > >> >> >>
> > > > >> >> >> Oleksandr Tyshchenko
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >
> > > > >> >> > --
> > > > >> >> > Regards,
> > > > >> >> > Bharat Gohil
> > > > >> >> > Sr.Software Engineer
> > > > >> >> > bharat.gohil@harman.com
> > > > >> >> > +919427054633
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> --
> > > > >> >> Regards,
> > > > >> >>
> > > > >> >> Oleksandr Tyshchenko
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Regards,
> > > > >> > Bharat Gohil
> > > > >> > Sr.Software Engineer
> > > > >> > bharat.gohil@harman.com
> > > > >> > +919427054633
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Regards,
> > > > >>
> > > > >> Oleksandr Tyshchenko
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Bharat Gohil
> > > > > Sr.Software Engineer
> > > > > bharat.gohil@harman.com
> > > > > +919427054633
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Oleksandr Tyshchenko
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > https://lists.xen.org/xen-devel
> > >
> >
> >
> >
> > --
> > Regards,
> > Bharat Gohil
> > Sr.Software Engineer
> > bharat.gohil@harman.com
> > +919427054633
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 33902 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-25 8:42 ` bharat gohil
@ 2017-09-25 12:15 ` Andrii Anisov
2017-09-25 12:53 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Andrii Anisov @ 2017-09-25 12:15 UTC (permalink / raw)
To: bharat gohil
Cc: Oleksandr Tyshchenko, Julien Grall, Stefano Stabellini, Xen Devel
Hello Bharat,
On 25.09.17 11:42, bharat gohil wrote:
> Hello Wilk,
>
> I had try Ctrl+a three times and 'd' but no dump on the serial console.
Its a way to switch to XEN debug console. In case you are using minicom,
you should press Ctrl+A six times, then you will see the line like
following:
(XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch
input to DOM0)
Then you can press 'h' for seeing installed key handlers.
But all of this requires XEN to be running somehow.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-25 12:15 ` Andrii Anisov
@ 2017-09-25 12:53 ` bharat gohil
2017-09-25 13:29 ` Julien Grall
2017-09-25 13:30 ` Andrii Anisov
0 siblings, 2 replies; 36+ messages in thread
From: bharat gohil @ 2017-09-25 12:53 UTC (permalink / raw)
To: Andrii Anisov
Cc: Oleksandr Tyshchenko, Julien Grall, Stefano Stabellini, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 810 bytes --]
Hello Andrii,
I tried but no success.
It looks, Xen is not running.
Thanks,
Bharat
On Mon, Sep 25, 2017 at 5:45 PM, Andrii Anisov <andrii_anisov@epam.com>
wrote:
> Hello Bharat,
>
>
> On 25.09.17 11:42, bharat gohil wrote:
>
>> Hello Wilk,
>>
>> I had try Ctrl+a three times and 'd' but no dump on the serial console.
>>
> Its a way to switch to XEN debug console. In case you are using minicom,
> you should press Ctrl+A six times, then you will see the line like
> following:
> (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch
> input to DOM0)
>
> Then you can press 'h' for seeing installed key handlers.
>
> But all of this requires XEN to be running somehow.
>
> --
>
> *Andrii Anisov*
>
>
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 1726 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-25 12:53 ` bharat gohil
@ 2017-09-25 13:29 ` Julien Grall
2017-09-25 17:40 ` bharat gohil
2017-09-25 13:30 ` Andrii Anisov
1 sibling, 1 reply; 36+ messages in thread
From: Julien Grall @ 2017-09-25 13:29 UTC (permalink / raw)
To: bharat gohil, Andrii Anisov
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Xen Devel
Hi,
On 09/25/2017 01:53 PM, bharat gohil wrote:
> Hello Andrii,
>
> I tried but no success.
> It looks, Xen is not running.
I am a bit confused... on one of the previous e-mail you posted log from
Xen:
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 272kB init memory.
So unless you have a completely new setup, Xen is definitely running.
However, what may happen is the serial driver in Xen does not receive
input characters.
One of the first test would be to check whether the driver effectively
receive characters.
Cheers,
>
> Thanks,
> Bharat
>
> On Mon, Sep 25, 2017 at 5:45 PM, Andrii Anisov <andrii_anisov@epam.com
> <mailto:andrii_anisov@epam.com>> wrote:
>
> Hello Bharat,
>
>
> On 25.09.17 11:42, bharat gohil wrote:
>
> Hello Wilk,
>
> I had try Ctrl+a three times and 'd' but no dump on the serial
> console.
>
> Its a way to switch to XEN debug console. In case you are using
> minicom, you should press Ctrl+A six times, then you will see the
> line like following:
> (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to
> switch input to DOM0)
>
> Then you can press 'h' for seeing installed key handlers.
>
> But all of this requires XEN to be running somehow.
>
> --
>
> *Andrii Anisov*
>
>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com <mailto:bharat.gohil@harman.com>
> +919427054633
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-25 12:53 ` bharat gohil
2017-09-25 13:29 ` Julien Grall
@ 2017-09-25 13:30 ` Andrii Anisov
1 sibling, 0 replies; 36+ messages in thread
From: Andrii Anisov @ 2017-09-25 13:30 UTC (permalink / raw)
To: bharat gohil
Cc: Oleksandr Tyshchenko, Julien Grall, Stefano Stabellini, Xen Devel
Hello Bharat,
On 25.09.17 15:53, bharat gohil wrote:
> Hello Andrii,
>
> I tried but no success.
> It looks, Xen is not running.
Or your dom0 kernel disabled serial port clock. Because from kernel
point of view it is left unused, like it happened to us with R-Car gen3
SoC. So we issued such a patch [1].
[1]
https://github.com/xen-troops/linux/commit/b4eec1abd5e683133ce8e326ced1986e7c65976a
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-25 13:29 ` Julien Grall
@ 2017-09-25 17:40 ` bharat gohil
2017-09-25 18:08 ` Oleksandr Tyshchenko
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-09-25 17:40 UTC (permalink / raw)
To: Julien Grall
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 1972 bytes --]
On 25-Sep-2017 6:59 PM, "Julien Grall" <julien.grall@arm.com> wrote:
Hi,
I am using same setup.
It just my guess because no response to key ctrl+a input.
SoC has 8250 compitible UART.I will print character in receive handler of
UART in Xen. Do we have any other hook test this?
One more thing, is big-little supported in xen?
How Xen distribute load among the CPUs or Xen only run in context of the
guest only?
In my setup Dom0 use energy aware scheduler.
Thanks,
Bharat
On 09/25/2017 01:53 PM, bharat gohil wrote:
> Hello Andrii,
>
> I tried but no success.
> It looks, Xen is not running.
>
I am a bit confused... on one of the previous e-mail you posted log from
Xen:
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
to Xen)
(XEN) Freed 272kB init memory.
So unless you have a completely new setup, Xen is definitely running.
However, what may happen is the serial driver in Xen does not receive input
characters.
One of the first test would be to check whether the driver effectively
receive characters.
Cheers,
> Thanks,
> Bharat
>
>
> On Mon, Sep 25, 2017 at 5:45 PM, Andrii Anisov <andrii_anisov@epam.com
> <mailto:andrii_anisov@epam.com>> wrote:
>
> Hello Bharat,
>
>
> On 25.09.17 11:42, bharat gohil wrote:
>
> Hello Wilk,
>
> I had try Ctrl+a three times and 'd' but no dump on the serial
> console.
>
> Its a way to switch to XEN debug console. In case you are using
> minicom, you should press Ctrl+A six times, then you will see the
> line like following:
> (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to
> switch input to DOM0)
>
> Then you can press 'h' for seeing installed key handlers.
>
> But all of this requires XEN to be running somehow.
>
> --
> *Andrii Anisov*
>
>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com <mailto:bharat.gohil@harman.com>
> +919427054633
>
--
Julien Grall
[-- Attachment #1.2: Type: text/html, Size: 3785 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-25 17:40 ` bharat gohil
@ 2017-09-25 18:08 ` Oleksandr Tyshchenko
2017-09-29 8:15 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Oleksandr Tyshchenko @ 2017-09-25 18:08 UTC (permalink / raw)
To: bharat gohil; +Cc: Julien Grall, Stefano Stabellini, Andrii Anisov, Xen Devel
Hi, Bharat
On Mon, Sep 25, 2017 at 8:40 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>
>
> On 25-Sep-2017 6:59 PM, "Julien Grall" <julien.grall@arm.com> wrote:
>
> Hi,
>
> I am using same setup.
> It just my guess because no response to key ctrl+a input.
>
> SoC has 8250 compitible UART.I will print character in receive handler of
> UART in Xen. Do we have any other hook test this?
Maybe you got stuck in the UART interrupt handler. Can you recheck?
If so, can you take a look at the patch which has been posted recently:
https://patchwork.kernel.org/patch/9959003/
>
> One more thing, is big-little supported in xen?
> How Xen distribute load among the CPUs or Xen only run in context of the
> guest only?
> In my setup Dom0 use energy aware scheduler.
>
> Thanks,
> Bharat
>
>
> On 09/25/2017 01:53 PM, bharat gohil wrote:
>>
>> Hello Andrii,
>>
>> I tried but no success.
>> It looks, Xen is not running.
>
>
> I am a bit confused... on one of the previous e-mail you posted log from
> Xen:
>
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to
> Xen)
>
> (XEN) Freed 272kB init memory.
>
> So unless you have a completely new setup, Xen is definitely running.
> However, what may happen is the serial driver in Xen does not receive input
> characters.
>
> One of the first test would be to check whether the driver effectively
> receive characters.
>
> Cheers,
>
>>
>> Thanks,
>> Bharat
>>
>>
>> On Mon, Sep 25, 2017 at 5:45 PM, Andrii Anisov <andrii_anisov@epam.com
>> <mailto:andrii_anisov@epam.com>> wrote:
>>
>> Hello Bharat,
>>
>>
>> On 25.09.17 11:42, bharat gohil wrote:
>>
>> Hello Wilk,
>>
>> I had try Ctrl+a three times and 'd' but no dump on the serial
>> console.
>>
>> Its a way to switch to XEN debug console. In case you are using
>> minicom, you should press Ctrl+A six times, then you will see the
>> line like following:
>> (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to
>> switch input to DOM0)
>>
>> Then you can press 'h' for seeing installed key handlers.
>>
>> But all of this requires XEN to be running somehow.
>>
>> --
>> *Andrii Anisov*
>>
>>
>>
>>
>>
>> --
>> Regards,
>> Bharat Gohil
>> Sr.Software Engineer
>> bharat.gohil@harman.com <mailto:bharat.gohil@harman.com>
>> +919427054633
>
>
> --
> Julien Grall
>
>
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-25 18:08 ` Oleksandr Tyshchenko
@ 2017-09-29 8:15 ` bharat gohil
2017-09-29 17:42 ` Julien Grall
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-09-29 8:15 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: Julien Grall, Stefano Stabellini, Andrii Anisov, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 2851 bytes --]
Hello
The patch didn't work in my case.
Thanks,
Bharat
On Mon, Sep 25, 2017 at 11:38 PM, Oleksandr Tyshchenko <olekstysh@gmail.com>
wrote:
> Hi, Bharat
>
> On Mon, Sep 25, 2017 at 8:40 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
> >
> >
> > On 25-Sep-2017 6:59 PM, "Julien Grall" <julien.grall@arm.com> wrote:
> >
> > Hi,
> >
> > I am using same setup.
> > It just my guess because no response to key ctrl+a input.
> >
> > SoC has 8250 compitible UART.I will print character in receive handler of
> > UART in Xen. Do we have any other hook test this?
>
> Maybe you got stuck in the UART interrupt handler. Can you recheck?
>
> If so, can you take a look at the patch which has been posted recently:
> https://patchwork.kernel.org/patch/9959003/
>
> >
> > One more thing, is big-little supported in xen?
> > How Xen distribute load among the CPUs or Xen only run in context of the
> > guest only?
> > In my setup Dom0 use energy aware scheduler.
> >
> > Thanks,
> > Bharat
> >
> >
> > On 09/25/2017 01:53 PM, bharat gohil wrote:
> >>
> >> Hello Andrii,
> >>
> >> I tried but no success.
> >> It looks, Xen is not running.
> >
> >
> > I am a bit confused... on one of the previous e-mail you posted log from
> > Xen:
> >
> > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to
> > Xen)
> >
> > (XEN) Freed 272kB init memory.
> >
> > So unless you have a completely new setup, Xen is definitely running.
> > However, what may happen is the serial driver in Xen does not receive
> input
> > characters.
> >
> > One of the first test would be to check whether the driver effectively
> > receive characters.
> >
> > Cheers,
> >
> >>
> >> Thanks,
> >> Bharat
> >>
> >>
> >> On Mon, Sep 25, 2017 at 5:45 PM, Andrii Anisov <andrii_anisov@epam.com
> >> <mailto:andrii_anisov@epam.com>> wrote:
> >>
> >> Hello Bharat,
> >>
> >>
> >> On 25.09.17 11:42, bharat gohil wrote:
> >>
> >> Hello Wilk,
> >>
> >> I had try Ctrl+a three times and 'd' but no dump on the serial
> >> console.
> >>
> >> Its a way to switch to XEN debug console. In case you are using
> >> minicom, you should press Ctrl+A six times, then you will see the
> >> line like following:
> >> (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to
> >> switch input to DOM0)
> >>
> >> Then you can press 'h' for seeing installed key handlers.
> >>
> >> But all of this requires XEN to be running somehow.
> >>
> >> --
> >> *Andrii Anisov*
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Bharat Gohil
> >> Sr.Software Engineer
> >> bharat.gohil@harman.com <mailto:bharat.gohil@harman.com>
> >> +919427054633
> >
> >
> > --
> > Julien Grall
> >
> >
>
>
>
> --
> Regards,
>
> Oleksandr Tyshchenko
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 4884 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-29 8:15 ` bharat gohil
@ 2017-09-29 17:42 ` Julien Grall
2017-10-03 7:05 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Julien Grall @ 2017-09-29 17:42 UTC (permalink / raw)
To: bharat gohil, Oleksandr Tyshchenko
Cc: Stefano Stabellini, Andrii Anisov, Konrad Rzeszutek Wilk, Xen Devel
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?
Cheers,
> Thanks,
> Bharat
>
> On Mon, Sep 25, 2017 at 11:38 PM, Oleksandr Tyshchenko
> <olekstysh@gmail.com <mailto:olekstysh@gmail.com>> wrote:
>
> Hi, Bharat
>
> On Mon, Sep 25, 2017 at 8:40 PM, bharat gohil <ghl.bhrt@gmail.com
> <mailto:ghl.bhrt@gmail.com>> wrote:
> >
> >
> > On 25-Sep-2017 6:59 PM, "Julien Grall" <julien.grall@arm.com <mailto:julien.grall@arm.com>> wrote:
> >
> > Hi,
> >
> > I am using same setup.
> > It just my guess because no response to key ctrl+a input.
> >
> > SoC has 8250 compitible UART.I will print character in receive handler of
> > UART in Xen. Do we have any other hook test this?
>
> Maybe you got stuck in the UART interrupt handler. Can you recheck?
>
> If so, can you take a look at the patch which has been posted recently:
> https://patchwork.kernel.org/patch/9959003/
> <https://patchwork.kernel.org/patch/9959003/>
>
> >
> > One more thing, is big-little supported in xen?
> > How Xen distribute load among the CPUs or Xen only run in context
> of the
> > guest only?
> > In my setup Dom0 use energy aware scheduler.
> >
> > Thanks,
> > Bharat
> >
> >
> > On 09/25/2017 01:53 PM, bharat gohil wrote:
> >>
> >> Hello Andrii,
> >>
> >> I tried but no success.
> >> It looks, Xen is not running.
> >
> >
> > I am a bit confused... on one of the previous e-mail you posted
> log from
> > Xen:
> >
> > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to
> switch input to
> > Xen)
> >
> > (XEN) Freed 272kB init memory.
> >
> > So unless you have a completely new setup, Xen is definitely running.
> > However, what may happen is the serial driver in Xen does not
> receive input
> > characters.
> >
> > One of the first test would be to check whether the driver
> effectively
> > receive characters.
> >
> > Cheers,
> >
> >>
> >> Thanks,
> >> Bharat
> >>
> >>
> >> On Mon, Sep 25, 2017 at 5:45 PM, Andrii Anisov
> <andrii_anisov@epam.com <mailto:andrii_anisov@epam.com>
> >> <mailto:andrii_anisov@epam.com <mailto:andrii_anisov@epam.com>>>
> wrote:
> >>
> >> Hello Bharat,
> >>
> >>
> >> On 25.09.17 11:42, bharat gohil wrote:
> >>
> >> Hello Wilk,
> >>
> >> I had try Ctrl+a three times and 'd' but no dump on the
> serial
> >> console.
> >>
> >> Its a way to switch to XEN debug console. In case you are using
> >> minicom, you should press Ctrl+A six times, then you will
> see the
> >> line like following:
> >> (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to
> >> switch input to DOM0)
> >>
> >> Then you can press 'h' for seeing installed key handlers.
> >>
> >> But all of this requires XEN to be running somehow.
> >>
> >> --
> >> *Andrii Anisov*
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Bharat Gohil
> >> Sr.Software Engineer
> >> bharat.gohil@harman.com <mailto:bharat.gohil@harman.com>
> <mailto:bharat.gohil@harman.com <mailto:bharat.gohil@harman.com>>
> >> +919427054633 <tel:%2B919427054633>
> >
> >
> > --
> > Julien Grall
> >
> >
>
>
>
> --
> Regards,
>
> Oleksandr Tyshchenko
>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com <mailto:bharat.gohil@harman.com>
> +919427054633
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-09-29 17:42 ` Julien Grall
@ 2017-10-03 7:05 ` bharat gohil
2017-10-06 13:29 ` Julien Grall
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2017-10-03 7:05 UTC (permalink / raw)
To: Julien Grall
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov,
Konrad Rzeszutek Wilk, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 4414 bytes --]
On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall <julien.grall@arm.com> 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,
>
> Cheers,
>
> Thanks,
>> Bharat
>>
>> On Mon, Sep 25, 2017 at 11:38 PM, Oleksandr Tyshchenko <
>> olekstysh@gmail.com <mailto:olekstysh@gmail.com>> wrote:
>>
>> Hi, Bharat
>>
>> On Mon, Sep 25, 2017 at 8:40 PM, bharat gohil <ghl.bhrt@gmail.com
>> <mailto:ghl.bhrt@gmail.com>> wrote:
>>
>> >
>> >
>> > On 25-Sep-2017 6:59 PM, "Julien Grall" <julien.grall@arm.com
>> <mailto:julien.grall@arm.com>> wrote:
>> >
>> > Hi,
>> >
>> > I am using same setup.
>> > It just my guess because no response to key ctrl+a input.
>> >
>> > SoC has 8250 compitible UART.I will print character in receive
>> handler of
>> > UART in Xen. Do we have any other hook test this?
>>
>> Maybe you got stuck in the UART interrupt handler. Can you recheck?
>>
>> If so, can you take a look at the patch which has been posted
>> recently:
>> https://patchwork.kernel.org/patch/9959003/
>> <https://patchwork.kernel.org/patch/9959003/>
>>
>> >
>> > One more thing, is big-little supported in xen?
>> > How Xen distribute load among the CPUs or Xen only run in context
>> of the
>> > guest only?
>> > In my setup Dom0 use energy aware scheduler.
>> >
>> > Thanks,
>> > Bharat
>> >
>> >
>> > On 09/25/2017 01:53 PM, bharat gohil wrote:
>> >>
>> >> Hello Andrii,
>> >>
>> >> I tried but no success.
>> >> It looks, Xen is not running.
>> >
>> >
>> > I am a bit confused... on one of the previous e-mail you posted
>> log from
>> > Xen:
>> >
>> > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to
>> switch input to
>> > Xen)
>> >
>> > (XEN) Freed 272kB init memory.
>> >
>> > So unless you have a completely new setup, Xen is definitely
>> running.
>> > However, what may happen is the serial driver in Xen does not
>> receive input
>> > characters.
>> >
>> > One of the first test would be to check whether the driver
>> effectively
>> > receive characters.
>> >
>> > Cheers,
>> >
>> >>
>> >> Thanks,
>> >> Bharat
>> >>
>> >>
>> >> On Mon, Sep 25, 2017 at 5:45 PM, Andrii Anisov
>> <andrii_anisov@epam.com <mailto:andrii_anisov@epam.com>
>> >> <mailto:andrii_anisov@epam.com <mailto:andrii_anisov@epam.com>>>
>> wrote:
>> >>
>> >> Hello Bharat,
>> >>
>> >>
>> >> On 25.09.17 11:42, bharat gohil wrote:
>> >>
>> >> Hello Wilk,
>> >>
>> >> I had try Ctrl+a three times and 'd' but no dump on the
>> serial
>> >> console.
>> >>
>> >> Its a way to switch to XEN debug console. In case you are
>> using
>> >> minicom, you should press Ctrl+A six times, then you will
>> see the
>> >> line like following:
>> >> (XEN) *** Serial input -> Xen (type 'CTRL-a' three times
>> to
>> >> switch input to DOM0)
>> >>
>> >> Then you can press 'h' for seeing installed key handlers.
>> >>
>> >> But all of this requires XEN to be running somehow.
>> >>
>> >> --
>> >> *Andrii Anisov*
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Bharat Gohil
>> >> Sr.Software Engineer
>> >> bharat.gohil@harman.com <mailto:bharat.gohil@harman.com>
>> <mailto:bharat.gohil@harman.com <mailto:bharat.gohil@harman.com>>
>> >> +919427054633 <tel:%2B919427054633>
>> >
>> >
>> > --
>> > Julien Grall
>> >
>> >
>>
>>
>>
>> --
>> Regards,
>>
>> Oleksandr Tyshchenko
>>
>>
>>
>>
>> --
>> Regards,
>> Bharat Gohil
>> Sr.Software Engineer
>> bharat.gohil@harman.com <mailto:bharat.gohil@harman.com>
>> +919427054633
>>
>
> --
> Julien Grall
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 8298 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-10-03 7:05 ` bharat gohil
@ 2017-10-06 13:29 ` Julien Grall
2018-02-22 8:43 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Julien Grall @ 2017-10-06 13:29 UTC (permalink / raw)
To: bharat gohil
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov,
Konrad Rzeszutek Wilk, Xen Devel
Hello,
On 03/10/17 08:05, bharat gohil wrote:
>
>
> On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall <julien.grall@arm.com
> <mailto:julien.grall@arm.com>> 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.
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2017-10-06 13:29 ` Julien Grall
@ 2018-02-22 8:43 ` bharat gohil
2018-02-22 9:45 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2018-02-22 8:43 UTC (permalink / raw)
To: Julien Grall
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 3135 bytes --]
On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall <julien.grall@arm.com> wrote:
> Hello,
>
> On 03/10/17 08:05, bharat gohil wrote:
>
>>
>>
>> On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall <julien.grall@arm.com
>> <mailto:julien.grall@arm.com>> 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..
>
> 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@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 4498 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2018-02-22 8:43 ` bharat gohil
@ 2018-02-22 9:45 ` bharat gohil
2018-02-22 10:33 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2018-02-22 9:45 UTC (permalink / raw)
To: Julien Grall
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 3610 bytes --]
On Thu, Feb 22, 2018 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>
>
> On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall <julien.grall@arm.com> wrote:
>
>> Hello,
>>
>> On 03/10/17 08:05, bharat gohil wrote:
>>
>>>
>>>
>>> On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall <julien.grall@arm.com
>>> <mailto:julien.grall@arm.com>> 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.
>
>> 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@harman.com
> +919427054633 <+91%2094270%2054633>
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 5800 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2018-02-22 9:45 ` bharat gohil
@ 2018-02-22 10:33 ` bharat gohil
2018-02-22 10:38 ` bharat gohil
` (3 more replies)
0 siblings, 4 replies; 36+ messages in thread
From: bharat gohil @ 2018-02-22 10:33 UTC (permalink / raw)
To: Julien Grall
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 5586 bytes --]
On Thu, Feb 22, 2018 at 3:15 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>
>
> On Thu, Feb 22, 2018 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>
>>
>>
>> On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall <julien.grall@arm.com>
>> wrote:
>>
>>> Hello,
>>>
>>> On 03/10/17 08:05, bharat gohil wrote:
>>>
>>>>
>>>>
>>>> On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall <julien.grall@arm.com
>>>> <mailto:julien.grall@arm.com>> 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 hand 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@harman.com
>> +919427054633 <+91%2094270%2054633>
>>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com
> +919427054633 <+91%2094270%2054633>
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 8905 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2018-02-22 10:33 ` bharat gohil
@ 2018-02-22 10:38 ` bharat gohil
2018-02-22 11:01 ` Andrii Anisov
` (2 subsequent siblings)
3 siblings, 0 replies; 36+ messages in thread
From: bharat gohil @ 2018-02-22 10:38 UTC (permalink / raw)
To: Julien Grall
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 6174 bytes --]
typo
On Thu, Feb 22, 2018 at 4:03 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>
>
> On Thu, Feb 22, 2018 at 3:15 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>
>>
>>
>> On Thu, Feb 22, 2018 at 2:13 PM, bharat gohil <ghl.bhrt@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall <julien.grall@arm.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> On 03/10/17 08:05, bharat gohil wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall <julien.grall@arm.com
>>>>> <mailto:julien.grall@arm.com>> 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@harman.com
>>> +919427054633 <+91%2094270%2054633>
>>>
>>
>>
>>
>> --
>> Regards,
>> Bharat Gohil
>> Sr.Software Engineer
>> bharat.gohil@harman.com
>> +919427054633 <+91%2094270%2054633>
>>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.gohil@harman.com
> +919427054633 <+91%2094270%2054633>
>
--
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.gohil@harman.com
+919427054633
[-- Attachment #1.2: Type: text/html, Size: 10369 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2018-02-22 10:33 ` bharat gohil
2018-02-22 10:38 ` bharat gohil
@ 2018-02-22 11:01 ` Andrii Anisov
2018-02-22 11:20 ` Julien Grall
2018-02-22 11:11 ` Andrii Anisov
2018-02-22 11:27 ` Julien Grall
3 siblings, 1 reply; 36+ messages in thread
From: Andrii Anisov @ 2018-02-22 11:01 UTC (permalink / raw)
To: bharat gohil
Cc: Oleksandr Tyshchenko, Julien Grall, Stefano Stabellini, Xen Devel
Hello Bharat,
On 22.02.18 12:33, bharat gohil wrote:
> System got hand 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.
There is a nit which is overlooked often: XEN hypervisor does not pass
an input device tree as is to Dom0. Especially CPU and memory nodes.
They are created by XEN itself accordingly to dom0 configuration.
Literally Dom0 receives device tree with VCPUs and domain RAM space
description instead of PCPUs and machine RAM description. In your
particular case, I guess, scheduler is looking for some specific
properties in CPU nodes, but do not find them, because XEN creates basic
CPU nodes from the scratch.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2018-02-22 10:33 ` bharat gohil
2018-02-22 10:38 ` bharat gohil
2018-02-22 11:01 ` Andrii Anisov
@ 2018-02-22 11:11 ` Andrii Anisov
2018-02-22 11:27 ` Julien Grall
3 siblings, 0 replies; 36+ messages in thread
From: Andrii Anisov @ 2018-02-22 11:11 UTC (permalink / raw)
To: bharat gohil, Julien Grall
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Xen Devel
Hello Bharat,
Threads [1], [2] should feed your interest about big.LITTLE support in XEN.
[1] -
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00079.html
[2] -
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01695.html
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2018-02-22 11:01 ` Andrii Anisov
@ 2018-02-22 11:20 ` Julien Grall
0 siblings, 0 replies; 36+ messages in thread
From: Julien Grall @ 2018-02-22 11:20 UTC (permalink / raw)
To: Andrii Anisov, bharat gohil
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Xen Devel
On 22/02/18 11:01, Andrii Anisov wrote:
> On 22.02.18 12:33, bharat gohil wrote:
>> System got hand 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.
> There is a nit which is overlooked often: XEN hypervisor does not pass
> an input device tree as is to Dom0. Especially CPU and memory nodes.
> They are created by XEN itself accordingly to dom0 configuration.
> Literally Dom0 receives device tree with VCPUs and domain RAM space
> description instead of PCPUs and machine RAM description. In your
> particular case, I guess, scheduler is looking for some specific
> properties in CPU nodes, but do not find them, because XEN creates basic
> CPU nodes from the scratch.
That's just a red-herring. You should never hang because of missing
properties for the CPU scheduling.
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2018-02-22 10:33 ` bharat gohil
` (2 preceding siblings ...)
2018-02-22 11:11 ` Andrii Anisov
@ 2018-02-22 11:27 ` Julien Grall
2018-02-26 7:31 ` bharat gohil
3 siblings, 1 reply; 36+ messages in thread
From: Julien Grall @ 2018-02-22 11:27 UTC (permalink / raw)
To: bharat gohil
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov, Xen Devel
Hi,
Please configure your e-mail client to quote with '>'. It is incredibly
difficult to read e-mail when space is used for quoting (see below).
On 22/02/18 10:33, bharat gohil wrote:
> 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.
This looks quite wrong to me. By modifying the interrupt parent
property, you also modify which interrupt controller will be used for
routing the interrupt. This is probably the reason of the hang you
mention below.
What are the interrupts controller you have on your platform?
>
>
> System got hand 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
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2018-02-22 11:27 ` Julien Grall
@ 2018-02-26 7:31 ` bharat gohil
2018-02-26 10:21 ` Julien Grall
0 siblings, 1 reply; 36+ messages in thread
From: bharat gohil @ 2018-02-26 7:31 UTC (permalink / raw)
To: Julien Grall
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov, Xen Devel
[-- Attachment #1.1: Type: text/plain, Size: 4658 bytes --]
Regards,
Bharat Gohil
On Thu, Feb 22, 2018 at 4:57 PM, Julien Grall <julien.grall@arm.com> wrote:
> Hi,
>
> Please configure your e-mail client to quote with '>'. It is incredibly
> difficult to read e-mail when space is used for quoting (see below).
>
>
> On 22/02/18 10:33, bharat gohil wrote:
>
>> 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.
>>
>
> This looks quite wrong to me. By modifying the interrupt parent property,
> you also modify which interrupt controller will be used for routing the
> interrupt. This is probably the reason of the hang you mention below.
>
> What are the interrupts controller you have on your platform?
>
> >It has interrupt controller which change the polarity of SPI IRQ before
redirect to GIC-400.
>In DTB debug, I got following trace,
>(XEN) irq 0 not connected to primary controller. Connected to
/intpol-controller@10220a80.
>I think Xen skip interrupt controller(if other than GIC) while domain
creation.
>Do you have suggestion to solve this?
>Do I need to support custom IRQ controller in Xen or hard code the custom
controller register in Xen and modified DTB with GIC as primary controller?
>
>
>>
>> System got hand 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
>>
>
> Cheers,
>
> --
> Julien Grall
>
[-- Attachment #1.2: Type: text/html, Size: 6366 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2018-02-26 7:31 ` bharat gohil
@ 2018-02-26 10:21 ` Julien Grall
2018-02-26 13:09 ` bharat gohil
0 siblings, 1 reply; 36+ messages in thread
From: Julien Grall @ 2018-02-26 10:21 UTC (permalink / raw)
To: bharat gohil
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov, Xen Devel
Hi,
What I meant by using '>' for quoting is all my reply should be prefixed
with '>'. You write your reply normally.
You can do that in gmail by switching the e-mail from HTML to plain text.
On 26/02/18 07:31, bharat gohil wrote:
> On Thu, Feb 22, 2018 at 4:57 PM, Julien Grall <julien.grall@arm.com
> <mailto:julien.grall@arm.com>> wrote:
> This looks quite wrong to me. By modifying the interrupt parent
> property, you also modify which interrupt controller will be used
> for routing the interrupt. This is probably the reason of the hang
> you mention below.
>
> What are the interrupts controller you have on your platform?
>
> >It has interrupt controller which change the polarity of SPI IRQ
> before redirect to GIC-400.
> >In DTB debug, I got following trace,
> >(XEN) irq 0 not connected to primary controller. Connected to
> /intpol-controller@10220a80.
> >I think Xen skip interrupt controller(if other than GIC) while domain
> creation.
Xen will not try to map interrupt that are routed to a different
interrupt controller. This is because we don't know how to translate the
property 'regs' for those interrupts.
> >Do you have suggestion to solve this?
> >Do I need to support custom IRQ controller in Xen or hard code the
> custom controller register in Xen and modified DTB with GIC as primary
> controller?
If any interrupts used by Xen (e.g UART) are behind that custom IRQ
controller, then you would need to add the driver in Xen.
There was an attempt to provide a framework for hooking custom IRQ
controller in Xen (see [1]).
You could probably look for doing something similar for your board.
Cheers,
[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg00991.html
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: ARM64:Porting xen to new hardware
2018-02-26 10:21 ` Julien Grall
@ 2018-02-26 13:09 ` bharat gohil
0 siblings, 0 replies; 36+ messages in thread
From: bharat gohil @ 2018-02-26 13:09 UTC (permalink / raw)
To: Julien Grall
Cc: Oleksandr Tyshchenko, Stefano Stabellini, Andrii Anisov, Xen Devel
On Mon, Feb 26, 2018 at 3:51 PM, Julien Grall <julien.grall@arm.com> wrote:
> Hi,
>
> What I meant by using '>' for quoting is all my reply should be prefixed
> with '>'. You write your reply normally.
>
> You can do that in gmail by switching the e-mail from HTML to plain text.
>
Ok. Got it.
> On 26/02/18 07:31, bharat gohil wrote:
>>
>> On Thu, Feb 22, 2018 at 4:57 PM, Julien Grall <julien.grall@arm.com
>> <mailto:julien.grall@arm.com>> wrote:
>> This looks quite wrong to me. By modifying the interrupt parent
>> property, you also modify which interrupt controller will be used
>> for routing the interrupt. This is probably the reason of the hang
>> you mention below.
>>
>> What are the interrupts controller you have on your platform?
>>
>> >It has interrupt controller which change the polarity of SPI IRQ before
>> redirect to GIC-400.
>> >In DTB debug, I got following trace,
>> >(XEN) irq 0 not connected to primary controller. Connected to
>> /intpol-controller@10220a80.
>> >I think Xen skip interrupt controller(if other than GIC) while domain
>> creation.
>
>
> Xen will not try to map interrupt that are routed to a different interrupt
> controller. This is because we don't know how to translate the property
> 'regs' for those interrupts.
>
>> >Do you have suggestion to solve this?
>> >Do I need to support custom IRQ controller in Xen or hard code the
>> custom controller register in Xen and modified DTB with GIC as primary
>> controller?
>
>
> If any interrupts used by Xen (e.g UART) are behind that custom IRQ
> controller, then you would need to add the driver in Xen.
>
> There was an attempt to provide a framework for hooking custom IRQ
> controller in Xen (see [1]).
>
> You could probably look for doing something similar for your board.
>
Thanks lot for your hint. I am able to get login prompt for Dom0.
> Cheers,
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg00991.html
>
>
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2018-02-26 13:09 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-29 14:21 ARM64:Porting xen to new hardware bharat gohil
2017-08-30 14:14 ` Oleksandr Tyshchenko
2017-08-30 14:30 ` bharat gohil
2017-08-31 11:13 ` bharat gohil
2017-08-31 11:58 ` Oleksandr Tyshchenko
2017-09-04 4:13 ` bharat gohil
2017-09-04 12:54 ` Oleksandr Tyshchenko
2017-09-06 7:01 ` bharat gohil
2017-09-06 10:19 ` Oleksandr Tyshchenko
2017-09-07 13:30 ` bharat gohil
2017-09-08 19:19 ` Oleksandr Tyshchenko
2017-09-18 14:46 ` Konrad Rzeszutek Wilk
2017-09-22 10:00 ` bharat gohil
2017-09-22 13:43 ` Konrad Rzeszutek Wilk
2017-09-25 8:42 ` bharat gohil
2017-09-25 12:15 ` Andrii Anisov
2017-09-25 12:53 ` bharat gohil
2017-09-25 13:29 ` Julien Grall
2017-09-25 17:40 ` bharat gohil
2017-09-25 18:08 ` Oleksandr Tyshchenko
2017-09-29 8:15 ` bharat gohil
2017-09-29 17:42 ` Julien Grall
2017-10-03 7:05 ` bharat gohil
2017-10-06 13:29 ` Julien Grall
2018-02-22 8:43 ` bharat gohil
2018-02-22 9:45 ` bharat gohil
2018-02-22 10:33 ` bharat gohil
2018-02-22 10:38 ` bharat gohil
2018-02-22 11:01 ` Andrii Anisov
2018-02-22 11:20 ` Julien Grall
2018-02-22 11:11 ` Andrii Anisov
2018-02-22 11:27 ` Julien Grall
2018-02-26 7:31 ` bharat gohil
2018-02-26 10:21 ` Julien Grall
2018-02-26 13:09 ` bharat gohil
2017-09-25 13:30 ` Andrii Anisov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.