XEN on R-CAR H3

XEN on R-CAR H3

[Amit Tomer]

HI,

Trying to boot XEN on R-CAR H3 starter Kit board.

Linux image based on 5.0.0-rc5 and XEN image is 4.12

tftp 0x48000000 xen;tftp 0x7a000000 Image; tftp 4a000000 r8a7795-h3ulcb.dtb
setenv xen_addr_r 0x48000000
setenv fdt_addr_r 4a000000
setenv kernel_addr_r 0x7a000000
fdt addr $fdt_addr_r
fdt resize
fdt set /chosen xen,xen-bootargs "console=dtuart dom0_mem=384M"
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt mknod /chosen module@0
fdt resize
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <$kernel_addr_r 0x1800000>
setenv bootargs "console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused
rootwait earlycon=xenboot"

But when It boot it, I see following crash:


booti 0x48000000 - 0x4a000000
## Flattened Device Tree blob at 4a000000
 Booting using the fdt blob at 0x4a000000
reserving fdt memory region: addr=4a000000 size=10000
Using Device Tree in place at 000000004a000000, end
000000004a012fff

 Starting kernel ...
 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: 0000000048000000 - 000000007fffffff
(XEN) RAM: 0000000500000000 - 000000053fffffff
(XEN) RAM: 0000000600000000 - 000000063fffffff
(XEN) RAM: 0000000700000000 - 000000073fffffff
(XEN) RAM: 0000000500000000 - 000000053fffffff
(XEN) RAM: 0000000600000000 - 000000063fffffff
(XEN) RAM: 0000000700000000 - 000000073fffffff
(XEN)
(XEN) MODULE[0]: 000000004a000000 - 000000004a010000 Device Tree
(XEN) MODULE[1]: 000000007a000000 - 000000007b800000 Kernel
(XEN)  RESVD[0]: 000000004a000000 - 000000004a010000
(XEN)
(XEN)
(XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=384M
(XEN) PFN compression on bits 19...19
(XEN) Xen BUG at page_alloc.c:274
(XEN) ----[ Xen-4.12.0-rc  arm64  debug=y   Not tainted ]----
(XEN) CPU:    0
(XEN) PC:     000000000028b30c page_alloc.c#bootmem_region_add+0x184/0x194
(XEN) LR:     000000000028b36c
(XEN) SP:     00000000002d7d00
(XEN) CPSR:   800003c9 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)      X0: 0000000000500000  X1: 0000000000000003  X2: 0000000000000006
(XEN)      X3: 0000000000540000  X4: 0000800008121000  X5: 0000000000000028
(XEN)      X6: 0000000000600000  X7: 0000000000000004  X8: 0000000000000001
(XEN)      X9: 000000000000000a X10: 00000000002d7afa X11: 0000000000000031
(XEN)     X12: 0000000000000002 X13: 000000000026e5e8 X14: 0000000000000020
(XEN)     X15: 0000000000400000 X16: 0000000000000000 X17: 0000000000000000
(XEN)     X18: 000000007d726e08 X19: 0000000000500000 X20: 0000000000540000
(XEN)     X21: 0000000540000000 X22: 0000000500000000 X23: 0000000540000000
(XEN)     X24: 000000000028b31c X25: 00000000002b8400 X26: 0000000048000000
(XEN)     X27: 0000000740000000 X28: 0000000000000004  FP: 00000000002d7d00
(XEN)
(XEN)   VTCR_EL2: 80000000
(XEN)  VTTBR_EL2: 0000000000000000
(XEN)
(XEN)  SCTLR_EL2: 30cd183d
(XEN)    HCR_EL2: 0000000000000038
(XEN)  TTBR0_EL2: 0000000048114000
(XEN)
(XEN)    ESR_EL2: f2000001
(XEN)  HPFAR_EL2: 0000000000000000
(XEN)    FAR_EL2: 0000000000000000
(XEN)
(XEN) Xen stack trace from sp=00000000002d7d00:
(XEN)    00000000002d7d40 000000000028b36c 0000000000000001 0000000500000000
(XEN)    0000000540000000 0000000500000000 0000000540000000 00000000002d7d90
(XEN)    00000000002d7d90 000000000029c8f8 0000000000000001 0000000500000000
(XEN)    0000000540000000 0000000500000000 0000000540000000 0000000000000001
(XEN)    00000000002e0000 0000000500000000 00000000002d7de0 000000000029dac0
(XEN)    0000000540000000 0000000500000000 0000000540000000 00000000002b83c0
(XEN)    ffffffffffffffff 00000000002b83d8 000000004a000000 000000004a010000
(XEN)    000000007d726a90 0000000000200608 0000000048000000 0000000047e00000
(XEN)    000000004a000000 0000000000000000 0000000000400000 0000000000000000
(XEN)    0000000000000001 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000010000 000000004a000000 0000000138000000
(XEN)    00000000002b83c0 000000000028b31c 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000300000000 ffffffff00000000 0000040000000040
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) Xen call trace:
(XEN)    [<000000000028b30c>] page_alloc.c#bootmem_region_add+0x184/0x194 (PC)
(XEN)    [<000000000028b36c>] init_boot_pages+0x50/0x17c (LR)
(XEN)    [<000000000028b36c>] init_boot_pages+0x50/0x17c
(XEN)    [<000000000029c8f8>] dt_unreserved_regions+0xc8/0xdc
(XEN)    [<000000000029dac0>] start_xen+0xbe8/0xc58
(XEN)    [<0000000000200608>] arm64/head.o#paging+0x60/0x98
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at page_alloc.c:274
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

Is there something obvious , I am missing ?

Thanks,
-Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 06.02.19 16:41, Amit Tomer wrote:
> HI,

Hi

>
> Trying to boot XEN on R-CAR H3 starter Kit board.
>
> Linux image based on 5.0.0-rc5 and XEN image is 4.12
>
> tftp 0x48000000 xen;tftp 0x7a000000 Image; tftp 4a000000 r8a7795-h3ulcb.dtb
> setenv xen_addr_r 0x48000000
> setenv fdt_addr_r 4a000000
> setenv kernel_addr_r 0x7a000000
> fdt addr $fdt_addr_r
> fdt resize
> fdt set /chosen xen,xen-bootargs "console=dtuart dom0_mem=384M"
> fdt set /chosen \#address-cells <1>
> fdt set /chosen \#size-cells <1>
> fdt mknod /chosen module@0
> fdt resize
> fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
> fdt set /chosen/module@0 reg <$kernel_addr_r 0x1800000>
> setenv bootargs "console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused
> rootwait earlycon=xenboot"
>
> But when It boot it, I see following crash:
>
>
> booti 0x48000000 - 0x4a000000
> ## Flattened Device Tree blob at 4a000000
>   Booting using the fdt blob at 0x4a000000
> reserving fdt memory region: addr=4a000000 size=10000
> Using Device Tree in place at 000000004a000000, end
> 000000004a012fff
>
>   Starting kernel ...
>   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: 0000000048000000 - 000000007fffffff
> (XEN) RAM: 0000000500000000 - 000000053fffffff
> (XEN) RAM: 0000000600000000 - 000000063fffffff
> (XEN) RAM: 0000000700000000 - 000000073fffffff
> (XEN) RAM: 0000000500000000 - 000000053fffffff
> (XEN) RAM: 0000000600000000 - 000000063fffffff
> (XEN) RAM: 0000000700000000 - 000000073fffffff

Memory nodes got duplicated somehow. Likely U-Boot did something incorrect.

Try to use single memory node in your device-tree instead of separated 
by each bank nodes:

memory@48000000 {
         device_type = "memory";
         /* first 128MB is reserved for secure area. */
         reg = <0x0 0x48000000 0x0 0x38000000>,
               <0x5 0x00000000 0x0 0x40000000>,
               <0x6 0x00000000 0x0 0x40000000>,
               <0x7 0x00000000 0x0 0x40000000>;
};

-- 

Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi,Thanks for prompt reply.

> Memory nodes got duplicated somehow. Likely U-Boot did something incorrect.
>
> Try to use single memory node in your device-tree instead of separated
> by each bank nodes:
>
> memory@48000000 {
>          device_type = "memory";
>          /* first 128MB is reserved for secure area. */
>          reg = <0x0 0x48000000 0x0 0x38000000>,
>                <0x5 0x00000000 0x0 0x40000000>,
>                <0x6 0x00000000 0x0 0x40000000>,
>                <0x7 0x00000000 0x0 0x40000000>;
> };
>
> --
Sorry, I should have read the other thread completely where Andrii
Anisov has suggested the same.
Would try changes mentioned by you.

Thanks
-Amit

> Regards,
>
> Oleksandr Tyshchenko
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi,

> Would try changes mentioned by you.

We managed to boot XEN with dom0 kernel on H3.

But we see following , when we try to domU guest:

# xl create -c config.xl
Parsing config from config.xl
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
/etc/xen/scripts/block add [2417] exited with error status 1
libxl: error: libxl_device.c:1286:device_hotplug_child_death_cb:
script: File /home/amit_new/guest_domU/rootfs.img is read-only, and so
I willt
mount it read-write in a guest domain.
libxl: error: libxl_create.c:1318:domcreate_launch_dm: Domain 1:unable
to add disk devices
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
/etc/xen/scripts/block remove [2461] exited with error status 1
libxl: error: libxl_device.c:1286:device_hotplug_child_death_cb:
script: /etc/xen/scripts/block failed; error detected.
(XEN) mm.c:1401:d0v0 gnttab_mark_dirty not implemented yet
libxl: error: libxl_domain.c:1038:libxl__destroy_domid: Domain
1:Non-existant domain
libxl: error: libxl_domain.c:993:domain_destroy_callback: Domain
1:Unable to destroy guest
libxl: error: libxl_domain.c:920:domain_destroy_cb: Domain
1:Destruction of domain failed

where #cat config.xl
name = "guest-1"
kernel = "Image"
extra = "root=/dev/xvda rw xencons=tty console=hvc0"
memory = 256
vcpus = 1
disk = [ 'rootfs.img,raw,xvda,rw' ]

Any idea what is going wrong here ?

-Thanks,
Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 08.02.19 20:21, Amit Tomer wrote:
> Hi,

Hi

>> Would try changes mentioned by you.
> We managed to boot XEN with dom0 kernel on H3.

That's great.

> But we see following , when we try to domU guest:
>
> # xl create -c config.xl
> Parsing config from config.xl
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
> /etc/xen/scripts/block add [2417] exited with error status 1
> libxl: error: libxl_device.c:1286:device_hotplug_child_death_cb:
> script: File /home/amit_new/guest_domU/rootfs.img is read-only, and so
> I willt
> mount it read-write in a guest domain.
> libxl: error: libxl_create.c:1318:domcreate_launch_dm: Domain 1:unable
> to add disk devices
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
> /etc/xen/scripts/block remove [2461] exited with error status 1
> libxl: error: libxl_device.c:1286:device_hotplug_child_death_cb:
> script: /etc/xen/scripts/block failed; error detected.
> (XEN) mm.c:1401:d0v0 gnttab_mark_dirty not implemented yet
> libxl: error: libxl_domain.c:1038:libxl__destroy_domid: Domain
> 1:Non-existant domain
> libxl: error: libxl_domain.c:993:domain_destroy_callback: Domain
> 1:Unable to destroy guest
> libxl: error: libxl_domain.c:920:domain_destroy_cb: Domain
> 1:Destruction of domain failed
>
> where #cat config.xl
> name = "guest-1"
> kernel = "Image"
> extra = "root=/dev/xvda rw xencons=tty console=hvc0"
> memory = 256
> vcpus = 1
> disk = [ 'rootfs.img,raw,xvda,rw' ]
>
> Any idea what is going wrong here ?

Looks like, something incorrect with you block device settings.

Maybe, enabling verbose output will provide more informative output:

xl -v -v -v create -c config.xl


I assume, your have the following option enabled in your Linux defconfig:

CONFIG_XEN_BLKDEV_BACKEND=y


Personally I have never tried to run guest domain with such disk option:

disk = [ 'rootfs.img,raw,xvda,rw' ]

So, can't say anything about it.


Do you have any storage device in your Dom0 (SD, eMMC, etc)? If yes, you 
can put rootfs for your guest domain on it.

And then add the following to guest config file, taking care of changing 
it according to actual partitions:

disk = [ 'phy:/dev/sda1,xvda1' ]

or

disk = [ 'phy:/dev/mmcblk1p1,xvda1' ]

This everything works for me.


>
> -Thanks,
> Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi,

> disk = [ 'phy:/dev/mmcblk1p1,xvda1' ]

Thanks , this worked for us and we can now boot Linux guest in domU.

But now, while booting Android as domU guest , we don't get console
login for domU and it stuck
here:

[   10.597394] usbcore: registered new interface driver cdc_acm
[   10.597436] cdc_acm: USB Abstract Control Model driver for USB
modems and ISDN adapters
[   10.599829] file system registered
[   10.611942] kauditd_printk_skb: 6 callbacks suppressed
[   10.611947] audit: type=1400 audit(1550239280.843:17): avc:  denied
 { entrypoint } for  pid=864 comm="init" path="/system/bin/adbd"
dev="xvda1" ino=889 scontext=u:r:adbd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   10.616842] audit: type=1400 audit(1550239280.847:18): avc:  denied
 { map } for  pid=864 comm="adbd" path="/system/bin/adbd" dev="xvda1"
ino=889 scontext=u:r:adbd:s0 tcontext=u:object_r:unlabeled:s0
tclass=file permissive=1
[   10.617012] audit: type=1400 audit(1550239280.851:19): avc:  denied
 { read execute } for  pid=864 comm="adbd" path="/system/bin/adbd"
dev="xvda1" ino=889 scontext=u:r:adbd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   10.747628] random: adbd: uninitialized urandom read (40 bytes read)

Is there a special way to give hvc console login in Android , the way
we do it in Ubuntu is to create hvc0.conf file?

Thanks
- Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 15.02.19 16:17, Amit Tomer wrote:
> Hi,

Hi


>
>> disk = [ 'phy:/dev/mmcblk1p1,xvda1' ]
> Thanks , this worked for us and we can now boot Linux guest in domU.

Sounds great


>
> But now, while booting Android as domU guest , we don't get console
> login for domU and it stuck
> here:
>
> [   10.597394] usbcore: registered new interface driver cdc_acm
> [   10.597436] cdc_acm: USB Abstract Control Model driver for USB
> modems and ISDN adapters
> [   10.599829] file system registered
> [   10.611942] kauditd_printk_skb: 6 callbacks suppressed
> [   10.611947] audit: type=1400 audit(1550239280.843:17): avc:  denied
>   { entrypoint } for  pid=864 comm="init" path="/system/bin/adbd"
> dev="xvda1" ino=889 scontext=u:r:adbd:s0
> tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
> [   10.616842] audit: type=1400 audit(1550239280.847:18): avc:  denied
>   { map } for  pid=864 comm="adbd" path="/system/bin/adbd" dev="xvda1"
> ino=889 scontext=u:r:adbd:s0 tcontext=u:object_r:unlabeled:s0
> tclass=file permissive=1
> [   10.617012] audit: type=1400 audit(1550239280.851:19): avc:  denied
>   { read execute } for  pid=864 comm="adbd" path="/system/bin/adbd"
> dev="xvda1" ino=889 scontext=u:r:adbd:s0
> tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
> [   10.747628] random: adbd: uninitialized urandom read (40 bytes read)
>
> Is there a special way to give hvc console login in Android , the way
> we do it in Ubuntu is to create hvc0.conf file?

I am wondering what Android version you are using. What is your use-case?

I am not familiar with Android internals, but AFAIK we don't perform any 
special actions to make Android happy using hvc, except the following:
1. Add "console=hvc0" to kernel command line
2. Set CONFIG_HVC_XEN=y, CONFIG_HVC_XEN_FRONTEND=y in kernel defconfig

This is our development product
https://github.com/xen-troops/meta-xt-prod-devel
which in addition to Linux guest contains Android P guest.

Here you can see how we implemented.


>
> Thanks
> - Amit

-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi,
> I am wondering what Android version you are using. What is your use-case?

We are trying with Android O 8.1 version.

> This is our development product
> https://github.com/xen-troops/meta-xt-prod-devel
> which in addition to Linux guest contains Android P guest.
>
After making some changes in domU bootargs, we can now see
console service trying to start but goes into loop with message:

[    6.432864] init: starting service 'console'...
[    6.433974] init: property_set("ro.boottime.console", "6432469848")
failed: property already set
[    6.434580] init: setpgid failed for console: Operation not permitted
[    6.434743] init: cannot setexeccon('u:r:shell:s0') for console:
Permission denied
[    6.435434] init: Service 'console' (pid 781) killed by signal 6
[    6.435483] init: Sending signal 9 to service 'console' (pid 781)
process group...
[    6.435608] init: Successfully killed process cgroup uid 2000 pid 781 in 0ms

Also, one other query. In order to get graphics and audio up in dom0
kernel, do we
need to load special/proprietary graphics/audio driver with mainline kernel
and Ubuntu Debian rootfs on H3 platform?

Thanks
-Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 18.02.19 14:53, Amit Tomer wrote:

Hi

> Hi,
>> I am wondering what Android version you are using. What is your use-case?
> We are trying with Android O 8.1 version.
>
>> This is our development product
>> https://github.com/xen-troops/meta-xt-prod-devel
>> which in addition to Linux guest contains Android P guest.
>>
> After making some changes in domU bootargs, we can now see
> console service trying to start but goes into loop with message:
>
> [    6.432864] init: starting service 'console'...
> [    6.433974] init: property_set("ro.boottime.console", "6432469848")
> failed: property already set
> [    6.434580] init: setpgid failed for console: Operation not permitted
> [    6.434743] init: cannot setexeccon('u:r:shell:s0') for console:
> Permission denied
> [    6.435434] init: Service 'console' (pid 781) killed by signal 6
> [    6.435483] init: Sending signal 9 to service 'console' (pid 781)
> process group...
> [    6.435608] init: Successfully killed process cgroup uid 2000 pid 781 in 0ms

Not completely sure, but looks like the SELinux issue.


> Also, one other query. In order to get graphics and audio up in dom0
> kernel, do we
> need to load special/proprietary graphics/audio driver with mainline kernel
> and Ubuntu Debian rootfs on H3 platform?


Unfortunately, I can't say regarding mainline kernel and Ubuntu Debian 
rootfs.

We use Linux (as rootfs as well) from Renesas BSP [1] in our DomD. In 
our development setup we have thin Dom0 (generic ARM V8 machine without 
any devices assigned), and all devices (including audio/display/graphic) 
are pass throughed to DomD (driver domain). So this DomD is entirely 
based on Renesas BSP.


So, I think, if you base your Dom0 (I assume it is 1:1 mapped) on BSP 
you will get audio/graphic functional out of the box.  But for mainline 
kernel usage, the out-tree graphics kernel driver should be modified to 
use recent Linux API.

[1]  https://elinux.org/R-Car/Boards/Yocto-Gen3

>
> Thanks
> -Amit

-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi

> [1]  https://elinux.org/R-Car/Boards/Yocto-Gen3

 We tried BSP release v3.15.0 from above link but see following message:

[   45.518865] => setenv xen_addr_r 0x48000000;setenv fdt_addr_r
0x4a000000;setenv kernel_addr_r 0x7a000000
[   52.430467] => setenv fdt_high 0xffffffff;fdt addr $fdt_addr_r;fdt resize
[   55.348938] => setenv xen_bootargs console=dtuart dom0_mem=512M
[   57.661868] => setenv dom0_bootargs console=hvc0,115200n8
earlycon=xenboot debug clk_ignore_unused root=/dev/mmcblk1 rw rootwait
[   59.813185] => fdt set /chosen xen,xen-bootargs \"$xen_bootargs\";
[   62.037351] => fdt set /chosen xen,dom0-bootargs
\"$dom0_bootargs\";fdt mknode /chosen modules
[   65.765571] => fdt set /chosen/modules '#address-cells' <1>;fdt set
/chosen/modules '#size-cells' <1>;fdt mknode /chosen/modules module@0
[   68.086099] => fdt set /chosen/modules/module@0 compatible
"xen,linux-zimage" "xen,multiboot-module"
[   70.205113] => fdt set /chosen/modules/module@0 reg <
$kernel_addr_r 0x1800000 >
[   72.165412] => booti ${xen_addr_r} - ${fdt_addr_r}
[   74.021004] ## Flattened Device Tree blob at 4a000000
[   74.026244]    Booting using the fdt blob at 0x4a000000
[   74.031691]    reserving fdt memory region: addr=48000000 size=40000
[   74.038310]    reserving fdt memory region: addr=4a000000 size=12000
[   74.044936]    Loading Device Tree to 000000007d710000, end
000000007d724fff ... OK
[   74.054036]
[   74.055489] Starting kernel ...
[   74.058755]
- 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: 0000000048000000 - 000000007fffffff
(XEN) RAM: 0000000500000000 - 000000053fffffff
(XEN) RAM: 0000000600000000 - 000000063fffffff
(XEN) RAM: 0000000700000000 - 000000073fffffff
(XEN)
(XEN) MODULE[0]: 000000007d710000 - 000000007d722000 Device Tree
(XEN) MODULE[1]: 000000007a000000 - 000000007b800000 Kernel
(XEN)  RESVD[0]: 0000000048000000 - 0000000048040000
(XEN)  RESVD[1]: 000000004a000000 - 000000004a012000
(XEN)  RESVD[2]: 000000007d710000 - 000000007d722000
(XEN)
(XEN)
(XEN) Command line: console=dtuart dom0_mem=512M
(XEN) PFN compression on bits 19...19
(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 "115200n8"
(XEN) WARNING: UART configuration is not supported
 Xen 4.12.0-rc
(XEN) Xen version 4.12.0-rc (amit@) (aarch64-linux-gnu-gcc (Linaro GCC
7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y  Wed Feb  6
16:23:25 I9
(XEN) Latest ChangeSet: Thu Jan 24 14:03:48 2019 +0000 git:755eb64
(XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
(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: 0000000000001124 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 SMC Calling Convention v1.1
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv2 initialization:
(XEN)         gic_dist_addr=00000000f1010000
(XEN)         gic_cpu_addr=00000000f1020000
(XEN)         gic_hyp_addr=00000000f1040000
(XEN)         gic_vcpu_addr=00000000f1060000
(XEN)         gic_maintenance_irq=25
(XEN) GICv2: Adjusting CPU interface base to 0xf102f000
(XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN)  First cpu on runqueue, activating
(XEN) Allocated console ring of 64 KiB.
(XEN) Bringing up CPU1
- CPU 00000001 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Adding cpu 1 to runqueue 0
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 00000002 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Adding cpu 2 to runqueue 0
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 00000003 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Adding cpu 3 to runqueue 0
(XEN) CPU 3 booted.
(XEN) Bringing up CPU4
- CPU 00000100 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU4 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
(XEN) disable cpu (see big.LITTLE.txt under docs/).
(XEN) CPU4 never came online
(XEN) Failed to bring up CPU 4 (error -5)
(XEN) Bringing up CPU5
- CPU 00000101 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU5 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
(XEN) disable cpu (see big.LITTLE.txt under docs/).
(XEN) CPU5 never came online
(XEN) Failed to bring up CPU 5 (error -5)
(XEN) Bringing up CPU6
- CPU 00000102 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU6 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
(XEN) disable cpu (see big.LITTLE.txt under docs/).
(XEN) CPU6 never came online
(XEN) Failed to bring up CPU 6 (error -5)
(XEN) Bringing up CPU7
- CPU 00000103 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU7 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
(XEN) disable cpu (see big.LITTLE.txt under docs/).
(XEN) CPU7 never came online
(XEN) Failed to bring up CPU 7 (error -5)
(XEN) Brought up 4 CPUs
(XEN) P2M: 44-bit IPA with 44-bit PA and 8-bit VMID
(XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594
(XEN) I/O virtualisation disabled
(XEN) build-id: 74f80103afa98953c029eea87d69696bcd5ef69d
(XEN) alternatives: Patching with alt table 00000000002abba8 -> 00000000002ac1f0
(XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) CPU3 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) CPU1 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading Domd0 kernel from boot module @ 000000007a000000
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x00000050000000-0x00000070000000 (512MB)
(XEN) Grant table range: 0x00000048000000-0x00000048040000
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading zImage from 000000007a000000 to 0000000050080000-0000000051880000
(XEN) Loading dom0 DTB to 0x0000000058000000-0x0000000058010a48
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Unable to copy the DTB to dom0 memory (left = 68168 bytes)
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

But if we use mainline DTS with BSP release v3.15.0 based kernel , We
don't see above issue.
Any idea whats going wrong ?

Thanks
-Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 19.02.19 18:46, Amit Tomer wrote:
> Hi

Hi


>
>> [1]  https://elinux.org/R-Car/Boards/Yocto-Gen3
>   We tried BSP release v3.15.0 from above link but see following message:
>
> [   45.518865] => setenv xen_addr_r 0x48000000;setenv fdt_addr_r
> 0x4a000000;setenv kernel_addr_r 0x7a000000
> [   52.430467] => setenv fdt_high 0xffffffff;fdt addr $fdt_addr_r;fdt resize
> [   55.348938] => setenv xen_bootargs console=dtuart dom0_mem=512M
> [   57.661868] => setenv dom0_bootargs console=hvc0,115200n8
> earlycon=xenboot debug clk_ignore_unused root=/dev/mmcblk1 rw rootwait
> [   59.813185] => fdt set /chosen xen,xen-bootargs \"$xen_bootargs\";
> [   62.037351] => fdt set /chosen xen,dom0-bootargs
> \"$dom0_bootargs\";fdt mknode /chosen modules
> [   65.765571] => fdt set /chosen/modules '#address-cells' <1>;fdt set
> /chosen/modules '#size-cells' <1>;fdt mknode /chosen/modules module@0
> [   68.086099] => fdt set /chosen/modules/module@0 compatible
> "xen,linux-zimage" "xen,multiboot-module"
> [   70.205113] => fdt set /chosen/modules/module@0 reg <
> $kernel_addr_r 0x1800000 >
> [   72.165412] => booti ${xen_addr_r} - ${fdt_addr_r}
> [   74.021004] ## Flattened Device Tree blob at 4a000000
> [   74.026244]    Booting using the fdt blob at 0x4a000000
> [   74.031691]    reserving fdt memory region: addr=48000000 size=40000
> [   74.038310]    reserving fdt memory region: addr=4a000000 size=12000
> [   74.044936]    Loading Device Tree to 000000007d710000, end
> 000000007d724fff ... OK
> [   74.054036]
> [   74.055489] Starting kernel ...
> [   74.058755]
> - 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: 0000000048000000 - 000000007fffffff
> (XEN) RAM: 0000000500000000 - 000000053fffffff
> (XEN) RAM: 0000000600000000 - 000000063fffffff
> (XEN) RAM: 0000000700000000 - 000000073fffffff
> (XEN)
> (XEN) MODULE[0]: 000000007d710000 - 000000007d722000 Device Tree
> (XEN) MODULE[1]: 000000007a000000 - 000000007b800000 Kernel
> (XEN)  RESVD[0]: 0000000048000000 - 0000000048040000
> (XEN)  RESVD[1]: 000000004a000000 - 000000004a012000
> (XEN)  RESVD[2]: 000000007d710000 - 000000007d722000
> (XEN)
> (XEN)
> (XEN) Command line: console=dtuart dom0_mem=512M
> (XEN) PFN compression on bits 19...19
> (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 "115200n8"
> (XEN) WARNING: UART configuration is not supported
>   Xen 4.12.0-rc
> (XEN) Xen version 4.12.0-rc (amit@) (aarch64-linux-gnu-gcc (Linaro GCC
> 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
> d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y  Wed Feb  6
> 16:23:25 I9
> (XEN) Latest ChangeSet: Thu Jan 24 14:03:48 2019 +0000 git:755eb64
> (XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
> (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: 0000000000001124 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 SMC Calling Convention v1.1
> (XEN) Using PSCI v1.0
> (XEN) SMP: Allowing 8 CPUs
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
> (XEN) GICv2 initialization:
> (XEN)         gic_dist_addr=00000000f1010000
> (XEN)         gic_cpu_addr=00000000f1020000
> (XEN)         gic_hyp_addr=00000000f1040000
> (XEN)         gic_vcpu_addr=00000000f1060000
> (XEN)         gic_maintenance_irq=25
> (XEN) GICv2: Adjusting CPU interface base to 0xf102f000
> (XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
> (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
> (XEN) Initializing Credit2 scheduler
> (XEN)  load_precision_shift: 18
> (XEN)  load_window_shift: 30
> (XEN)  underload_balance_tolerance: 0
> (XEN)  overload_balance_tolerance: -3
> (XEN)  runqueues arrangement: socket
> (XEN)  cap enforcement granularity: 10ms
> (XEN) load tracking window length 1073741824 ns
> (XEN) Adding cpu 0 to runqueue 0
> (XEN)  First cpu on runqueue, activating
> (XEN) Allocated console ring of 64 KiB.
> (XEN) Bringing up CPU1
> - CPU 00000001 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Adding cpu 1 to runqueue 0
> (XEN) CPU 1 booted.
> (XEN) Bringing up CPU2
> - CPU 00000002 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Adding cpu 2 to runqueue 0
> (XEN) CPU 2 booted.
> (XEN) Bringing up CPU3
> - CPU 00000003 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Adding cpu 3 to runqueue 0
> (XEN) CPU 3 booted.
> (XEN) Bringing up CPU4
> - CPU 00000100 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU4 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
> (XEN) disable cpu (see big.LITTLE.txt under docs/).
> (XEN) CPU4 never came online
> (XEN) Failed to bring up CPU 4 (error -5)
> (XEN) Bringing up CPU5
> - CPU 00000101 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU5 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
> (XEN) disable cpu (see big.LITTLE.txt under docs/).
> (XEN) CPU5 never came online
> (XEN) Failed to bring up CPU 5 (error -5)
> (XEN) Bringing up CPU6
> - CPU 00000102 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU6 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
> (XEN) disable cpu (see big.LITTLE.txt under docs/).
> (XEN) CPU6 never came online
> (XEN) Failed to bring up CPU 6 (error -5)
> (XEN) Bringing up CPU7
> - CPU 00000103 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU7 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
> (XEN) disable cpu (see big.LITTLE.txt under docs/).
> (XEN) CPU7 never came online
> (XEN) Failed to bring up CPU 7 (error -5)
> (XEN) Brought up 4 CPUs
> (XEN) P2M: 44-bit IPA with 44-bit PA and 8-bit VMID
> (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594
> (XEN) I/O virtualisation disabled
> (XEN) build-id: 74f80103afa98953c029eea87d69696bcd5ef69d
> (XEN) alternatives: Patching with alt table 00000000002abba8 -> 00000000002ac1f0
> (XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) CPU3 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) CPU1 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading Domd0 kernel from boot module @ 000000007a000000
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x00000050000000-0x00000070000000 (512MB)
> (XEN) Grant table range: 0x00000048000000-0x00000048040000
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading zImage from 000000007a000000 to 0000000050080000-0000000051880000
> (XEN) Loading dom0 DTB to 0x0000000058000000-0x0000000058010a48
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Unable to copy the DTB to dom0 memory (left = 68168 bytes)
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> But if we use mainline DTS with BSP release v3.15.0 based kernel , We
> don't see above issue.
> Any idea whats going wrong ?

We use earlier BSP version and we didn't face the similar issue.

We have a plan to switch to recent BSP version (3.15). So, I will come 
up with updates when we migrate.


>
> Thanks
> -Amit

-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi,

> We use earlier BSP version and we didn't face the similar issue.
>
> We have a plan to switch to recent BSP version (3.15). So, I will come
> up with updates when we migrate.

Thanks for this information, we have now built it for 3.9 but yet to
test the images.
Also, it would be great if you can let us know the XEN version you use with BSP
images?

Thanks,
-Amit.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Julien Grall]

Hi Amit,

Thank you for the report.

On 2/19/19 4:46 PM, Amit Tomer wrote:
> (XEN) CPU7 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
> (XEN) disable cpu (see big.LITTLE.txt under docs/).
> (XEN) CPU7 never came online
> (XEN) Failed to bring up CPU 7 (error -5)
> (XEN) Brought up 4 CPUs
> (XEN) P2M: 44-bit IPA with 44-bit PA and 8-bit VMID
> (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594
> (XEN) I/O virtualisation disabled
> (XEN) build-id: 74f80103afa98953c029eea87d69696bcd5ef69d
> (XEN) alternatives: Patching with alt table 00000000002abba8 -> 00000000002ac1f0
> (XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) CPU3 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) CPU1 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading Domd0 kernel from boot module @ 000000007a000000
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x00000050000000-0x00000070000000 (512MB)
> (XEN) Grant table range: 0x00000048000000-0x00000048040000
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading zImage from 000000007a000000 to 0000000050080000-0000000051880000
> (XEN) Loading dom0 DTB to 0x0000000058000000-0x0000000058010a48
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Unable to copy the DTB to dom0 memory (left = 68168 bytes)
> (XEN) ****************************************

This is a bit odd. The function copy_to_guest_phys_flush_dcache can
only fail when the P2M entry is invalid or it is not a RAM page.

From the log, it can't even copy the first page. However, this seems 
to belong to the RAM (see BANK[0] message). Would you mind to apply the
following patch and send the log?


diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d9836779d1..08b9cd2c44 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1805,6 +1805,8 @@ static void __init dtb_load(struct kernel_info *kinfo)
     printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
            kinfo->dtb_paddr, kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
 
+    dump_p2m_lookup(kinfo->d, kinfo->dtb_paddr);
+
     left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
                                            kinfo->fdt,
                                            fdt_totalsize(kinfo->fdt));

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr Tyshchenko]

[-- Attachment #1.1: Type: text/plain, Size: 3621 bytes --]

ср, 20 февр. 2019 г., 22:14 Julien Grall <julien.grall@arm.com>:

> Hi Amit,


Hi, Julien, Amit.

Sorry for formatting, writing from my mobile.

If I am not mistaken, the diff between BSP's and mainline device trees is
in reserved memory area. BSP device tree (1) contains reserved memory
regions, but the mainline one (2) doesn't.
>From the log you provided, I see that Xen is trying to copy device-tree to
the address which is located in reserved area (0x58000000). FYI, we always
remove these reserved area nodes from the device-tree. Maybe that's why we
didn't face an issue. Julien, what do you think, can this be a reason?

(1)
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts?h=v4.14.75-ltsi/rcar-3.9.3.rc1

(2)
https://elixir.bootlin.com/linux/v5.0-rc7/source/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts


> Thank you for the report.
>
> On 2/19/19 4:46 PM, Amit Tomer wrote:
> > (XEN) CPU7 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
> > (XEN) disable cpu (see big.LITTLE.txt under docs/).
> > (XEN) CPU7 never came online
> > (XEN) Failed to bring up CPU 7 (error -5)
> > (XEN) Brought up 4 CPUs
> > (XEN) P2M: 44-bit IPA with 44-bit PA and 8-bit VMID
> > (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594
> > (XEN) I/O virtualisation disabled
> > (XEN) build-id: 74f80103afa98953c029eea87d69696bcd5ef69d
> > (XEN) alternatives: Patching with alt table 00000000002abba8 ->
> 00000000002ac1f0
> > (XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> > (XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> > (XEN) CPU3 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> > (XEN) CPU1 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> > (XEN) *** LOADING DOMAIN 0 ***
> > (XEN) Loading Domd0 kernel from boot module @ 000000007a000000
> > (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> > (XEN) BANK[0] 0x00000050000000-0x00000070000000 (512MB)
> > (XEN) Grant table range: 0x00000048000000-0x00000048040000
> > (XEN) Allocating PPI 16 for event channel interrupt
> > (XEN) Loading zImage from 000000007a000000 to
> 0000000050080000-0000000051880000
> > (XEN) Loading dom0 DTB to 0x0000000058000000-0x0000000058010a48
> > (XEN)
> > (XEN) ****************************************
> > (XEN) Panic on CPU 0:
> > (XEN) Unable to copy the DTB to dom0 memory (left = 68168 bytes)
> > (XEN) ****************************************
>
> This is a bit odd. The function copy_to_guest_phys_flush_dcache can
> only fail when the P2M entry is invalid or it is not a RAM page.
>
> From the log, it can't even copy the first page. However, this seems
> to belong to the RAM (see BANK[0] message). Would you mind to apply the
> following patch and send the log?
>
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d9836779d1..08b9cd2c44 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1805,6 +1805,8 @@ static void __init dtb_load(struct kernel_info
> *kinfo)
>      printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
>             kinfo->dtb_paddr, kinfo->dtb_paddr +
> fdt_totalsize(kinfo->fdt));
>
> +    dump_p2m_lookup(kinfo->d, kinfo->dtb_paddr);
> +
>      left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
>                                             kinfo->fdt,
>                                             fdt_totalsize(kinfo->fdt));
>
> Cheers,
>
> --
> Julien Grall
>

[-- Attachment #1.2: Type: text/html, Size: 5061 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

Re: XEN on R-CAR H3

[Julien Grall]

Hi Oleksandr,

On 20/02/2019 21:28, Oleksandr Tyshchenko wrote:
> ср, 20 февр. 2019 г., 22:14 Julien Grall <julien.grall@arm.com 
> <mailto:julien.grall@arm.com>>:
> If I am not mistaken, the diff between BSP's and mainline device trees is in 
> reserved memory area. BSP device tree (1) contains reserved memory regions, but 
> the mainline one (2) doesn't.
>  From the log you provided, I see that Xen is trying to copy device-tree to the 
> address which is located in reserved area (0x58000000). FYI, we always remove 
> these reserved area nodes from the device-tree. Maybe that's why we didn't face 
> an issue. Julien, what do you think, can this be a reason?
While I know that Xen does not deal with reserved area yet, we should have been 
able to write in that region. We don't even reach that state as we can't get the 
associated page.

It might be possible that the p2m entry is overwritten when going through the DT 
for mapping all the regions (see handle_device).

Printing the lookup would actually help to know what's going on.

Cheers,

-- 
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi,

> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d9836779d1..08b9cd2c44 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1805,6 +1805,8 @@ static void __init dtb_load(struct kernel_info *kinfo)
>      printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
>             kinfo->dtb_paddr, kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
>
> +    dump_p2m_lookup(kinfo->d, kinfo->dtb_paddr);
> +
>      left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
>                                             kinfo->fdt,
>                                             fdt_totalsize(kinfo->fdt));
>
Please find the logs after applying this patch:

(XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading Domd0 kernel from boot module @ 000000007a000000
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x00000050000000-0x00000070000000 (512MB)
(XEN) Grant table range: 0x00000048000000-0x00000048040000
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading zImage from 000000007a000000 to 0000000050080000-0000000051880000
(XEN) Loading dom0 DTB to 0x0000000058000000-0x0000000058010a44
(XEN) dom0 IPA 0x0000000058000000
(XEN) P2M @ 000000080c23dc90 mfn:0x73ff5e
(XEN) 0TH[0x0] = 0x008000073ff5c7ff
(XEN) 1ST[0x1] = 0x008000073ff3d7ff
(XEN) 2ND[0xc0] = 0x02c00000580006fd
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Unable to copy the DTB to dom0 memory (left = 68164 bytes)
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

Thanks
-Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi,

> (1) https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts?h=v4.14.75-ltsi/rcar-3.9.3.rc1
>
> (2) https://elixir.bootlin.com/linux/v5.0-rc7/source/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts

Yeah, this is what I thought initially but was not able to compile dts
file after removing the reserve node.

Will try it again, Thanks for pointing it out.

Thanks
-Amit.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 21.02.19 20:20, Amit Tomer wrote:
> Hi,

Hi


>
>> (1) https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts?h=v4.14.75-ltsi/rcar-3.9.3.rc1
>>
>> (2) https://elixir.bootlin.com/linux/v5.0-rc7/source/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> Yeah, this is what I thought initially but was not able to compile dts
> file after removing the reserve node.

Likely, it is because you left device nodes (mmngr,adsp,etc) which had 
links to reserved-memory regions ...


>
> Will try it again, Thanks for pointing it out.
>
> Thanks
> -Amit.

-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 21.02.19 12:11, Julien Grall wrote:
> Hi Oleksandr,

Hi, Julien, Amit


>
> On 20/02/2019 21:28, Oleksandr Tyshchenko wrote:
>> ср, 20 февр. 2019 г., 22:14 Julien Grall <julien.grall@arm.com
>> <mailto:julien.grall@arm.com>>:
>> If I am not mistaken, the diff between BSP's and mainline device trees is in
>> reserved memory area. BSP device tree (1) contains reserved memory regions, but
>> the mainline one (2) doesn't.
>>   From the log you provided, I see that Xen is trying to copy device-tree to the
>> address which is located in reserved area (0x58000000). FYI, we always remove
>> these reserved area nodes from the device-tree. Maybe that's why we didn't face
>> an issue. Julien, what do you think, can this be a reason?
> While I know that Xen does not deal with reserved area yet, we should have been
> able to write in that region. We don't even reach that state as we can't get the
> associated page.
>
> It might be possible that the p2m entry is overwritten when going through the DT
> for mapping all the regions (see handle_device).

Make sense.


I have just made an experiment. I returned reserved nodes back in my 
setup and got an fault, similar to what Amit had faced.


(XEN) handle /memory@48000000
(XEN)   Skip it (matched)
(XEN) handle /reserved-memory
(XEN) dt_irq_number: dev=/reserved-memory
(XEN) /reserved-memory passthrough = 1 nirq = 0 naddr = 0
(XEN) handle /reserved-memory/linux,lossy_decompress
(XEN) dt_irq_number: dev=/reserved-memory/linux,lossy_decompress
(XEN) /reserved-memory/linux,lossy_decompress passthrough = 1 nirq = 0 
naddr = 1
(XEN) DT: ** translation for device 
/reserved-memory/linux,lossy_decompress **
(XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
(XEN) DT: translating address:<3> 00000000<3> 54000000<3>
(XEN) DT: parent bus is default (na=2, ns=2) on /
(XEN) DT: empty ranges; 1:1 translation
(XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
(XEN) DT: with offset: 54000000
(XEN) DT: one level translation:<3> 00000000<3> 54000000<3>
(XEN) DT: reached root node
(XEN)   - MMIO: 0054000000 - 0057000000 P2MType=5
(XEN) handle /reserved-memory/linux,adsp
(XEN) dt_irq_number: dev=/reserved-memory/linux,adsp
(XEN) /reserved-memory/linux,adsp passthrough = 1 nirq = 0 naddr = 1
(XEN) DT: ** translation for device /reserved-memory/linux,adsp **
(XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
(XEN) DT: translating address:<3> 00000000<3> 57000000<3>
(XEN) DT: parent bus is default (na=2, ns=2) on /
(XEN) DT: empty ranges; 1:1 translation
(XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
(XEN) DT: with offset: 57000000
(XEN) DT: one level translation:<3> 00000000<3> 57000000<3>
(XEN) DT: reached root node
(XEN)   - MMIO: 0057000000 - 0058000000 P2MType=5
(XEN) handle /reserved-memory/linux,cma
(XEN) dt_irq_number: dev=/reserved-memory/linux,cma
(XEN) /reserved-memory/linux,cma passthrough = 1 nirq = 0 naddr = 1
(XEN) DT: ** translation for device /reserved-memory/linux,cma **
(XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
(XEN) DT: translating address:<3> 00000000<3> 58000000<3>
(XEN) DT: parent bus is default (na=2, ns=2) on /
(XEN) DT: empty ranges; 1:1 translation
(XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
(XEN) DT: with offset: 58000000
(XEN) DT: one level translation:<3> 00000000<3> 58000000<3>
(XEN) DT: reached root node
*(XEN)   - MMIO: 0058000000 - 0070000000 P2MType=5*
(XEN) handle /reserved-memory/linux,multimedia
(XEN) dt_irq_number: dev=/reserved-memory/linux,multimedia
(XEN) /reserved-memory/linux,multimedia passthrough = 1 nirq = 0 naddr = 1
(XEN) DT: ** translation for device /reserved-memory/linux,multimedia **
(XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
(XEN) DT: translating address:<3> 00000000<3> 70000000<3>
(XEN) DT: parent bus is default (na=2, ns=2) on /
(XEN) DT: empty ranges; 1:1 translation
(XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
(XEN) DT: with offset: 70000000
(XEN) DT: one level translation:<3> 00000000<3> 70000000<3>
(XEN) DT: reached root node
(XEN)   - MMIO: 0070000000 - 0080000000 P2MType=5
(XEN) handle /mmngr
(XEN) dt_irq_number: dev=/mmngr
(XEN) /mmngr passthrough = 1 nirq = 0 naddr = 0
(XEN) handle /mmngrbuf
(XEN) dt_irq_number: dev=/mmngrbuf
(XEN) /mmngrbuf passthrough = 1 nirq = 0 naddr = 0
(XEN) handle /vspm_if
(XEN) dt_irq_number: dev=/vspm_if
(XEN) /vspm_if passthrough = 1 nirq = 0 naddr = 0
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Create hypervisor node
(XEN) Create PSCI node
(XEN) Create cpus node
(XEN) Create cpu@0 (logical CPUID: 0) node
(XEN) Create cpu@1 (logical CPUID: 1) node
(XEN) Create cpu@2 (logical CPUID: 2) node
(XEN) Create cpu@3 (logical CPUID: 3) node
(XEN) Create memory node (reg size 4, nr cells 4)
(XEN)   Bank 0: 0x60000000->0x70000000
*(XEN) Loading zImage from 000000007a000000 to 
0000000060080000-0000000062080000*
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Unable to copy the kernel in the hwdom memory
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


>
> Printing the lookup would actually help to know what's going on.
>
> Cheers,
>
-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

Hi Amit


> Likely, it is because you left device nodes (mmngr,adsp,etc) which had 
> links to reserved-memory regions ...
>

Did removing reserved-memory regions together with users work out well 
for you?


-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hello,

> Did removing reserved-memory regions together with users work out well
> for you?

Sorry, didn't get chance to work on this today. I would test it and
let you know.

Thanks
-Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hello,

> > Did removing reserved-memory regions together with users work out well
> > for you?

Removing "reserved-memory" node along with "mmngr" worked well. Tested it
with v3.15 BSP release.

Also, just tried loading XEN from one of your branch[1] but it stuck with this:

[   13.793305] host 10.105.2.27 is alive
[   13.797050] => tftp 0x48000000 xen
[   20.944681] ravb:0 is connected to ravb.  Reconnecting to ravb
[   20.952032] ravb Waiting for PHY auto negotiation to complete... done
[   23.964201] ravb: 1000Base/Full
[   23.972794] Using ravb device
[   23.975792] TFTP from server 10.105.2.27; our IP address is 10.105.2.28
[   23.982685] Filename 'xen'.
[   23.985588] Load address: 0x48000000
[   23.989307] Loading:
#################################################################
[   29.073520]
#################################################################
[   29.155589]   ##################
[   29.178818]   141.6 KiB/s
[   29.181540] done
[   29.183447] Bytes transferred = 754000 (b8150 hex)
[   29.188789] => booti 0x48000000
[   34.990295] Image lacks image_size field, assuming 16MiB
[   34.995837]
[   34.997362] Starting kernel ...
[   35.000628]

Do we need to chose some other address where it should be loaded ?

[1]: https://github.com/otyshchenko1/xen/tree/ipmmu_v2

Thanks
 -Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 23.02.19 15:05, Amit Tomer wrote:
> Hello,

Hi


>
>>> Did removing reserved-memory regions together with users work out well
>>> for you?
> Removing "reserved-memory" node along with "mmngr" worked well. Tested it
> with v3.15 BSP release.

ok


>
> Also, just tried loading XEN from one of your branch[1] but it stuck with this:
>
> [   13.793305] host 10.105.2.27 is alive
> [   13.797050] => tftp 0x48000000 xen
> [   20.944681] ravb:0 is connected to ravb.  Reconnecting to ravb
> [   20.952032] ravb Waiting for PHY auto negotiation to complete... done
> [   23.964201] ravb: 1000Base/Full
> [   23.972794] Using ravb device
> [   23.975792] TFTP from server 10.105.2.27; our IP address is 10.105.2.28
> [   23.982685] Filename 'xen'.
> [   23.985588] Load address: 0x48000000
> [   23.989307] Loading:
> #################################################################
> [   29.073520]
> #################################################################
> [   29.155589]   ##################
> [   29.178818]   141.6 KiB/s
> [   29.181540] done
> [   29.183447] Bytes transferred = 754000 (b8150 hex)
> [   29.188789] => booti 0x48000000
> [   34.990295] Image lacks image_size field, assuming 16MiB
> [   34.995837]
> [   34.997362] Starting kernel ...
> [   35.000628]
>
> Do we need to chose some other address where it should be loaded ?

We usually load Xen to 0x48080000...


I think, it is up to you to what address to load images in U-Boot.

Just to be sure that you won't overwrite something else in memory 
(stack, other images, etc)...


I would suggest you to build with early printk support enabled and see 
what is wrong.

CONFIG_EARLY_PRINTK=scif,0xe6e88000


BTW, we use mkimage tool to create Xen image to be loaded:

mkimage -A arm64 -C none -T kernel -a 0x78080000 -e 0x78080000 -n "XEN" 
xen/xen xen-uImage


>
> Thanks
>   -Amit

-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

Hi Julien


>> While I know that Xen does not deal with reserved area yet, we should 
>> have been
>> able to write in that region. We don't even reach that state as we 
>> can't get the
>> associated page.
>>
>> It might be possible that the p2m entry is overwritten when going 
>> through the DT
>> for mapping all the regions (see handle_device).
>
> Make sense.
>
>
> I have just made an experiment. I returned reserved nodes back in my 
> setup and got an fault, similar to what Amit had faced.
>
>
> (XEN) handle /memory@48000000
> (XEN)   Skip it (matched)
> (XEN) handle /reserved-memory
> (XEN) dt_irq_number: dev=/reserved-memory
> (XEN) /reserved-memory passthrough = 1 nirq = 0 naddr = 0
> (XEN) handle /reserved-memory/linux,lossy_decompress
> (XEN) dt_irq_number: dev=/reserved-memory/linux,lossy_decompress
> (XEN) /reserved-memory/linux,lossy_decompress passthrough = 1 nirq = 0 
> naddr = 1
> (XEN) DT: ** translation for device 
> /reserved-memory/linux,lossy_decompress **
> (XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
> (XEN) DT: translating address:<3> 00000000<3> 54000000<3>
> (XEN) DT: parent bus is default (na=2, ns=2) on /
> (XEN) DT: empty ranges; 1:1 translation
> (XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
> (XEN) DT: with offset: 54000000
> (XEN) DT: one level translation:<3> 00000000<3> 54000000<3>
> (XEN) DT: reached root node
> (XEN)   - MMIO: 0054000000 - 0057000000 P2MType=5
> (XEN) handle /reserved-memory/linux,adsp
> (XEN) dt_irq_number: dev=/reserved-memory/linux,adsp
> (XEN) /reserved-memory/linux,adsp passthrough = 1 nirq = 0 naddr = 1
> (XEN) DT: ** translation for device /reserved-memory/linux,adsp **
> (XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
> (XEN) DT: translating address:<3> 00000000<3> 57000000<3>
> (XEN) DT: parent bus is default (na=2, ns=2) on /
> (XEN) DT: empty ranges; 1:1 translation
> (XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
> (XEN) DT: with offset: 57000000
> (XEN) DT: one level translation:<3> 00000000<3> 57000000<3>
> (XEN) DT: reached root node
> (XEN)   - MMIO: 0057000000 - 0058000000 P2MType=5
> (XEN) handle /reserved-memory/linux,cma
> (XEN) dt_irq_number: dev=/reserved-memory/linux,cma
> (XEN) /reserved-memory/linux,cma passthrough = 1 nirq = 0 naddr = 1
> (XEN) DT: ** translation for device /reserved-memory/linux,cma **
> (XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
> (XEN) DT: translating address:<3> 00000000<3> 58000000<3>
> (XEN) DT: parent bus is default (na=2, ns=2) on /
> (XEN) DT: empty ranges; 1:1 translation
> (XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
> (XEN) DT: with offset: 58000000
> (XEN) DT: one level translation:<3> 00000000<3> 58000000<3>
> (XEN) DT: reached root node
> *(XEN)   - MMIO: 0058000000 - 0070000000 P2MType=5*
> (XEN) handle /reserved-memory/linux,multimedia
> (XEN) dt_irq_number: dev=/reserved-memory/linux,multimedia
> (XEN) /reserved-memory/linux,multimedia passthrough = 1 nirq = 0 naddr 
> = 1
> (XEN) DT: ** translation for device /reserved-memory/linux,multimedia **
> (XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
> (XEN) DT: translating address:<3> 00000000<3> 70000000<3>
> (XEN) DT: parent bus is default (na=2, ns=2) on /
> (XEN) DT: empty ranges; 1:1 translation
> (XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
> (XEN) DT: with offset: 70000000
> (XEN) DT: one level translation:<3> 00000000<3> 70000000<3>
> (XEN) DT: reached root node
> (XEN)   - MMIO: 0070000000 - 0080000000 P2MType=5
> (XEN) handle /mmngr
> (XEN) dt_irq_number: dev=/mmngr
> (XEN) /mmngr passthrough = 1 nirq = 0 naddr = 0
> (XEN) handle /mmngrbuf
> (XEN) dt_irq_number: dev=/mmngrbuf
> (XEN) /mmngrbuf passthrough = 1 nirq = 0 naddr = 0
> (XEN) handle /vspm_if
> (XEN) dt_irq_number: dev=/vspm_if
> (XEN) /vspm_if passthrough = 1 nirq = 0 naddr = 0
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Create hypervisor node
> (XEN) Create PSCI node
> (XEN) Create cpus node
> (XEN) Create cpu@0 (logical CPUID: 0) node
> (XEN) Create cpu@1 (logical CPUID: 1) node
> (XEN) Create cpu@2 (logical CPUID: 2) node
> (XEN) Create cpu@3 (logical CPUID: 3) node
> (XEN) Create memory node (reg size 4, nr cells 4)
> (XEN)   Bank 0: 0x60000000->0x70000000
> *(XEN) Loading zImage from 000000007a000000 to 
> 0000000060080000-0000000062080000*
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Unable to copy the kernel in the hwdom memory
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>

There is a question which worries me and likely other people as well. 
Which is "reserved memory area support in Xen". Some SoCs except 
application processors have some IPs (co-processors, dsps, codecs, 
whatever) which rely on a specific predefined memory regions, or even 
can work with these memory regions only...

Without this feature being supported, we won't be able to use IPs, whose 
firmware requires a predefined memory region to talk to an application 
processor, I am afraid.
One option comes to mind... I presume, the use of "iomem" property in 
domain config could allow us to assign 1:1 mapped region to that guest 
domain. Would it be a correct option?
What needs to be implementing it Xen, for example, to have a possibility 
to assign a particular reserved memory region(s) to a particular guest 
domain?

-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Julien Grall]

Hi Oleksandr,

On 2/25/19 2:43 PM, Oleksandr wrote:
> 
> Hi Julien
> 
> 
>>> While I know that Xen does not deal with reserved area yet, we should 
>>> have been
>>> able to write in that region. We don't even reach that state as we 
>>> can't get the
>>> associated page.
>>>
>>> It might be possible that the p2m entry is overwritten when going 
>>> through the DT
>>> for mapping all the regions (see handle_device).
>>
>> Make sense.
>>
>>
>> I have just made an experiment. I returned reserved nodes back in my 
>> setup and got an fault, similar to what Amit had faced.
>>
>>
>> (XEN) handle /memory@48000000
>> (XEN)   Skip it (matched)
>> (XEN) handle /reserved-memory
>> (XEN) dt_irq_number: dev=/reserved-memory
>> (XEN) /reserved-memory passthrough = 1 nirq = 0 naddr = 0
>> (XEN) handle /reserved-memory/linux,lossy_decompress
>> (XEN) dt_irq_number: dev=/reserved-memory/linux,lossy_decompress
>> (XEN) /reserved-memory/linux,lossy_decompress passthrough = 1 nirq = 0 
>> naddr = 1
>> (XEN) DT: ** translation for device 
>> /reserved-memory/linux,lossy_decompress **
>> (XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
>> (XEN) DT: translating address:<3> 00000000<3> 54000000<3>
>> (XEN) DT: parent bus is default (na=2, ns=2) on /
>> (XEN) DT: empty ranges; 1:1 translation
>> (XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
>> (XEN) DT: with offset: 54000000
>> (XEN) DT: one level translation:<3> 00000000<3> 54000000<3>
>> (XEN) DT: reached root node
>> (XEN)   - MMIO: 0054000000 - 0057000000 P2MType=5
>> (XEN) handle /reserved-memory/linux,adsp
>> (XEN) dt_irq_number: dev=/reserved-memory/linux,adsp
>> (XEN) /reserved-memory/linux,adsp passthrough = 1 nirq = 0 naddr = 1
>> (XEN) DT: ** translation for device /reserved-memory/linux,adsp **
>> (XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
>> (XEN) DT: translating address:<3> 00000000<3> 57000000<3>
>> (XEN) DT: parent bus is default (na=2, ns=2) on /
>> (XEN) DT: empty ranges; 1:1 translation
>> (XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
>> (XEN) DT: with offset: 57000000
>> (XEN) DT: one level translation:<3> 00000000<3> 57000000<3>
>> (XEN) DT: reached root node
>> (XEN)   - MMIO: 0057000000 - 0058000000 P2MType=5
>> (XEN) handle /reserved-memory/linux,cma
>> (XEN) dt_irq_number: dev=/reserved-memory/linux,cma
>> (XEN) /reserved-memory/linux,cma passthrough = 1 nirq = 0 naddr = 1
>> (XEN) DT: ** translation for device /reserved-memory/linux,cma **
>> (XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
>> (XEN) DT: translating address:<3> 00000000<3> 58000000<3>
>> (XEN) DT: parent bus is default (na=2, ns=2) on /
>> (XEN) DT: empty ranges; 1:1 translation
>> (XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
>> (XEN) DT: with offset: 58000000
>> (XEN) DT: one level translation:<3> 00000000<3> 58000000<3>
>> (XEN) DT: reached root node
>> *(XEN)   - MMIO: 0058000000 - 0070000000 P2MType=5*
>> (XEN) handle /reserved-memory/linux,multimedia
>> (XEN) dt_irq_number: dev=/reserved-memory/linux,multimedia
>> (XEN) /reserved-memory/linux,multimedia passthrough = 1 nirq = 0 naddr 
>> = 1
>> (XEN) DT: ** translation for device /reserved-memory/linux,multimedia **
>> (XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
>> (XEN) DT: translating address:<3> 00000000<3> 70000000<3>
>> (XEN) DT: parent bus is default (na=2, ns=2) on /
>> (XEN) DT: empty ranges; 1:1 translation
>> (XEN) DT: parent translation for:<3> 00000000<3> 00000000<3>
>> (XEN) DT: with offset: 70000000
>> (XEN) DT: one level translation:<3> 00000000<3> 70000000<3>
>> (XEN) DT: reached root node
>> (XEN)   - MMIO: 0070000000 - 0080000000 P2MType=5
>> (XEN) handle /mmngr
>> (XEN) dt_irq_number: dev=/mmngr
>> (XEN) /mmngr passthrough = 1 nirq = 0 naddr = 0
>> (XEN) handle /mmngrbuf
>> (XEN) dt_irq_number: dev=/mmngrbuf
>> (XEN) /mmngrbuf passthrough = 1 nirq = 0 naddr = 0
>> (XEN) handle /vspm_if
>> (XEN) dt_irq_number: dev=/vspm_if
>> (XEN) /vspm_if passthrough = 1 nirq = 0 naddr = 0
>> (XEN) Allocating PPI 16 for event channel interrupt
>> (XEN) Create hypervisor node
>> (XEN) Create PSCI node
>> (XEN) Create cpus node
>> (XEN) Create cpu@0 (logical CPUID: 0) node
>> (XEN) Create cpu@1 (logical CPUID: 1) node
>> (XEN) Create cpu@2 (logical CPUID: 2) node
>> (XEN) Create cpu@3 (logical CPUID: 3) node
>> (XEN) Create memory node (reg size 4, nr cells 4)
>> (XEN)   Bank 0: 0x60000000->0x70000000
>> *(XEN) Loading zImage from 000000007a000000 to 
>> 0000000060080000-0000000062080000*
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) Unable to copy the kernel in the hwdom memory
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>>
> 
> There is a question which worries me and likely other people as well. 
> Which is "reserved memory area support in Xen". Some SoCs except 
> application processors have some IPs (co-processors, dsps, codecs, 
> whatever) which rely on a specific predefined memory regions, or even 
> can work with these memory regions only...

This discussion came-up time to time on the ML. I would love to see 
patches we can discuss :)

> 
> Without this feature being supported, we won't be able to use IPs, whose 
> firmware requires a predefined memory region to talk to an application 
> processor, I am afraid.
> One option comes to mind... I presume, the use of "iomem" property in 
> domain config could allow us to assign 1:1 mapped region to that guest 
> domain. Would it be a correct option?
> What needs to be implementing it Xen, for example, to have a possibility 
> to assign a particular reserved memory region(s) to a particular guest 
> domain?

Well, for a first you need to deal with Xen and Dom0. For instance, Xen 
allocator should not be able to use that memory for a normal RAM page.

There was some discussions on the ML a long time ago with Andrii (see 
[1]). Maybe he has some patches ready for it.

Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02674.html

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

> Hi Oleksandr,

Hi, Julien


>> There is a question which worries me and likely other people as well. 
>> Which is "reserved memory area support in Xen". Some SoCs except 
>> application processors have some IPs (co-processors, dsps, codecs, 
>> whatever) which rely on a specific predefined memory regions, or even 
>> can work with these memory regions only...
>
> This discussion came-up time to time on the ML. I would love to see 
> patches we can discuss :)
>>
>> Without this feature being supported, we won't be able to use IPs, 
>> whose firmware requires a predefined memory region to talk to an 
>> application processor, I am afraid.
>> One option comes to mind... I presume, the use of "iomem" property in 
>> domain config could allow us to assign 1:1 mapped region to that 
>> guest domain. Would it be a correct option?
>> What needs to be implementing it Xen, for example, to have a 
>> possibility to assign a particular reserved memory region(s) to a 
>> particular guest domain?
>
> Well, for a first you need to deal with Xen and Dom0. For instance, 
> Xen allocator should not be able to use that memory for a normal RAM 
> page.

I understand.


>
> There was some discussions on the ML a long time ago with Andrii (see 
> [1]). Maybe he has some patches ready for it.
>
> Cheers,
>
> [1] 
> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02674.html


Thank you for the pointer. I will read it.


-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Julien Grall]

Hi Amit,

On 2/21/19 6:15 PM, Amit Tomer wrote:
> Hi,
> 
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index d9836779d1..08b9cd2c44 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1805,6 +1805,8 @@ static void __init dtb_load(struct kernel_info *kinfo)
>>       printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
>>              kinfo->dtb_paddr, kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
>>
>> +    dump_p2m_lookup(kinfo->d, kinfo->dtb_paddr);
>> +
>>       left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
>>                                              kinfo->fdt,
>>                                              fdt_totalsize(kinfo->fdt));
>>
> Please find the logs after applying this patch:
> 
> (XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading Domd0 kernel from boot module @ 000000007a000000
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x00000050000000-0x00000070000000 (512MB)
> (XEN) Grant table range: 0x00000048000000-0x00000048040000
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading zImage from 000000007a000000 to 0000000050080000-0000000051880000
> (XEN) Loading dom0 DTB to 0x0000000058000000-0x0000000058010a44
> (XEN) dom0 IPA 0x0000000058000000
> (XEN) P2M @ 000000080c23dc90 mfn:0x73ff5e
> (XEN) 0TH[0x0] = 0x008000073ff5c7ff
> (XEN) 1ST[0x1] = 0x008000073ff3d7ff
> (XEN) 2ND[0xc0] = 0x02c00000580006fd

Thank you for giving a try! The p2m type for the entry is p2m_mmio_direct_c.

This confirms the finding on the other threads. I would suggest you to 
remove the reserved-memory nodes until Xen gain knowledge of reserved 
memory.

FIY, Stefano has posted a patch series yesterday aiming to solve this 
issues.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

Hi, Amit

>
>
> BTW, we use mkimage tool to create Xen image to be loaded:
>
> mkimage -A arm64 -C none -T kernel -a 0x78080000 -e 0x78080000 -n 
> "XEN" xen/xen xen-uImage


I am sorry, I had missed "-d" key before xen image.

The proper command is:

mkimage -A arm64 -C none -T kernel -a 0x78080000 -e 0x78080000 -n "XEN" 
-d xen/xen xen-uImage


-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi,

> The proper command is:
>
> mkimage -A arm64 -C none -T kernel -a 0x78080000 -e 0x78080000 -n "XEN"
> -d xen/xen xen-uImage

Yeah but it didn't boot it up :(

[   16.991035] => setenv ipaddr 10.105.2.28;setenv serverip
10.105.2.27;ping 10.105.2.27
[   18.791456] ravb Waiting for PHY auto negotiation to complete... done
[   21.506184] ravb: 1000Base/Full
[   21.514787] Using ravb device
[   26.518321] host 10.105.2.27 is alive
[   26.522064] => tftp 0x48080000 xen-uImage
[   32.859274] ravb:0 is connected to ravb.  Reconnecting to ravb
[   32.866626] ravb Waiting for PHY auto negotiation to complete... done
[   35.936229] ravb: 1000Base/Full
[   35.944824] Using ravb device
[   35.947840] TFTP from server 10.105.2.27; our IP address is 10.105.2.28
[   35.954733] Filename 'xen-uImage'.
[   35.958271] Load address: 0x48080000
[   35.961990] Loading:
#################################################################
[   41.049127]
#################################################################
[   41.131627]   ##################
[   41.154635]   141.6 KiB/s
[   41.157357] done
[   41.159264] Bytes transferred = 754064 (b8190 hex)
[   41.164605] => bootm 0x48080000
[   48.511339] ## Booting kernel from Legacy Image at 48080000 ...
[   48.517501]    Image Name:   XEN
[   48.520855]    Image Type:   AArch64 Linux Kernel Image (uncompressed)
[   48.527659]    Data Size:    754000 Bytes = 736.3 KiB
[   48.532921]    Load Address: 48080000
[   48.536731]    Entry Point:  48080000
[   48.540541]    Verifying Checksum ... OK
[   48.548190]    Loading Kernel Image ... OK
[   48.554182]
[   48.555635] Starting kernel ...
[   48.558901]

We even tried loading it to 0x78080000.

Thanks
-Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 05.03.19 18:50, Amit Tomer wrote:
> Hi,


Hi, Amit

>
>> The proper command is:
>>
>> mkimage -A arm64 -C none -T kernel -a 0x78080000 -e 0x78080000 -n "XEN"
>> -d xen/xen xen-uImage
> Yeah but it didn't boot it up :(

Have you tried to enable early_prink?


AFAIR, I tested that branch (ipmmu_v2) before submitting RFC patch 
series [1] and it was functional.

But, I don't quite remember what the BSP version (U-Boot/ARM-TF) I had 
based on.


[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02679.html

>
> [   16.991035] => setenv ipaddr 10.105.2.28;setenv serverip
> 10.105.2.27;ping 10.105.2.27
> [   18.791456] ravb Waiting for PHY auto negotiation to complete... done
> [   21.506184] ravb: 1000Base/Full
> [   21.514787] Using ravb device
> [   26.518321] host 10.105.2.27 is alive
> [   26.522064] => tftp 0x48080000 xen-uImage
> [   32.859274] ravb:0 is connected to ravb.  Reconnecting to ravb
> [   32.866626] ravb Waiting for PHY auto negotiation to complete... done
> [   35.936229] ravb: 1000Base/Full
> [   35.944824] Using ravb device
> [   35.947840] TFTP from server 10.105.2.27; our IP address is 10.105.2.28
> [   35.954733] Filename 'xen-uImage'.
> [   35.958271] Load address: 0x48080000
> [   35.961990] Loading:
> #################################################################
> [   41.049127]
> #################################################################
> [   41.131627]   ##################
> [   41.154635]   141.6 KiB/s
> [   41.157357] done
> [   41.159264] Bytes transferred = 754064 (b8190 hex)
> [   41.164605] => bootm 0x48080000
> [   48.511339] ## Booting kernel from Legacy Image at 48080000 ...
> [   48.517501]    Image Name:   XEN
> [   48.520855]    Image Type:   AArch64 Linux Kernel Image (uncompressed)
> [   48.527659]    Data Size:    754000 Bytes = 736.3 KiB
> [   48.532921]    Load Address: 48080000
> [   48.536731]    Entry Point:  48080000
> [   48.540541]    Verifying Checksum ... OK
> [   48.548190]    Loading Kernel Image ... OK
> [   48.554182]
> [   48.555635] Starting kernel ...
> [   48.558901]
>
> We even tried loading it to 0x78080000.
>
> Thanks
> -Amit

-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi,
> Have you tried to enable early_prink?

Yes, this is how we compiled it.

make dist-xen XEN_TARGET_ARCH=arm64 debug=y
CROSS_COMPILE=aarch64-linux-gnu-
CONFIG_EARLY_PRINTK_salvator=scif,0xe6e88000 -j16

> AFAIR, I tested that branch (ipmmu_v2) before submitting RFC patch
> series [1] and it was functional.
>
> But, I don't quite remember what the BSP version (U-Boot/ARM-TF) I had
> based on.

Ok.

Thanks
-Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 05.03.19 20:10, Amit Tomer wrote:
> Hi,
>> Have you tried to enable early_prink?
> Yes, this is how we compiled it.
>
> make dist-xen XEN_TARGET_ARCH=arm64 debug=y
> CROSS_COMPILE=aarch64-linux-gnu-
> CONFIG_EARLY_PRINTK_salvator=scif,0xe6e88000 -j16

No, "CONFIG_EARLY_PRINTK_salvator=scif,0xe6e88000" is incorrect,

it should be "CONFIG_EARLY_PRINTK=scif,0xe6e88000". Probably, this is 
why you didn't see anything in console.


I have just tried to build (with early_printk support) and run that old 
Xen branch to see it booting.

-------------------------------------------------

Starting kernel ...

- 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) Initrd 0000000076000040-0000000077a230f7
(XEN) RAM: 0000000048000000 - 00000000bfffffff
(XEN) RAM: 0000000500000000 - 000000057fffffff
(XEN) RAM: 0000000600000000 - 000000067fffffff
(XEN) RAM: 0000000700000000 - 000000077fffffff
(XEN)
(XEN) MODULE[0]: 0000000048000000 - 0000000048014080 Device Tree
(XEN) MODULE[1]: 0000000076000040 - 0000000077a230f7 Ramdisk
(XEN) MODULE[2]: 000000007a000000 - 000000007c000000 Kernel
(XEN) MODULE[3]: 000000007c000000 - 000000007c010000 XSM
(XEN)  RESVD[0]: 0000000048000000 - 0000000048014000
(XEN)  RESVD[1]: 0000000076000040 - 0000000077a230f7
(XEN)
(XEN) Command line: dom0_mem=256M console=dtuart dtuart=serial0 
dom0_max_vcpus=4 bootscrub=0 loglvl=all
(XEN) Placing Xen at 0x000000077fe00000-0x0000000780000000
(XEN) Update BOOTMOD_XEN from 0000000078080000-00000000781b2d81 => 
000000077fe00000-000000077ff32d81
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Looking for dtuart at "serial0", options ""
(XEN) Unable to initialize dtuart: -9
(XEN) Bad console= option 'dtuart'
  *Xen 4.9.1-pre*
(XEN) Xen version 4.9.1-pre (otyshchenko@) (aarch64-poky-linux-gcc (GCC) 
7.3.0) debug=y  Tue Mar  5 20:57:55 EET 2019
(XEN) Latest ChangeSet: Mon May 8 13:45:21 2017 +0300 git:a438317-dirty
(XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
(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: 0000000000001124 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 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv2 initialization:
(XEN)         gic_dist_addr=00000000f1010000
(XEN)         gic_cpu_addr=00000000f1020000
(XEN)         gic_hyp_addr=00000000f1040000
(XEN)         gic_vcpu_addr=00000000f1060000
(XEN)         gic_maintenance_irq=25
(XEN) GICv2: Adjusting CPU interface base to 0xf102f000
(XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
(XEN) XSM Framework v1.0.0 initialized
(XEN) xsm: Policy len = 0x0000000000010000 start at 0x000000007c000000
(XEN) Flask: 128 avtab hash slots, 280 rules.
(XEN) Flask: 128 avtab hash slots, 280 rules.
(XEN) Flask:  4 users, 3 roles, 38 types, 2 bools
(XEN) Flask:  12 classes, 280 rules
(XEN) Flask:  Starting in enforcing mode.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 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 00000002 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 00000003 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 3 booted.
(XEN) Bringing up CPU4
- CPU 00000100 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 4 booted.
(XEN) Bringing up CPU5
- CPU 00000101 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 5 booted.
(XEN) Bringing up CPU6
- CPU 00000102 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 6 booted.
(XEN) Bringing up CPU7
- CPU 00000103 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 7 booted.
(XEN) Brought up 8 CPUs
(XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
(XEN) ipmmu: /soc/mmu@e67b0000: registered root IPMMU
(XEN) ipmmu: /soc/mmu@e67b0000: disable sharing P2M table between the 
CPU and IPMMU
(XEN) ipmmu: /soc/mmu@febd0000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef0000
(XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef1000
(XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef2000
(XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef3000
(XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/fcp@fea27000
(XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/fcp@fea2f000
(XEN) ipmmu: /soc/mmu@febe0000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef4000
(XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef5000
(XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef6000
(XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef7000
(XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/fcp@fea37000
(XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/hdmi@fead0000
(XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/hdmi@feae0000
(XEN) ipmmu: /soc/mmu@fe990000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@fe990000: found master device /soc/vspm@fe960000
(XEN) ipmmu: /soc/mmu@fe990000: found master device /soc/vspm@fe9a0000
(XEN) ipmmu: /soc/mmu@fe990000: found master device /soc/fdpm@fe940000
(XEN) ipmmu: /soc/mmu@fe980000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@fe980000: found master device /soc/vspm@fe920000
(XEN) ipmmu: /soc/mmu@fe980000: found master device /soc/vspm@fe9b0000
(XEN) ipmmu: /soc/mmu@fe980000: found master device /soc/fdpm@fe944000
(XEN) ipmmu: /soc/mmu@fe6b0000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@fe6b0000: found master device /soc/imr-lx4@fe880000
(XEN) ipmmu: /soc/mmu@fe6b0000: found master device /soc/imr-lx4@fe890000
(XEN) ipmmu: /soc/mmu@fe6b0000: found master device /soc/vcp4@fe90f000
(XEN) ipmmu: /soc/mmu@fe6f0000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@fe6f0000: found master device /soc/imr-lx4@fe860000
(XEN) ipmmu: /soc/mmu@fe6f0000: found master device /soc/imr-lx4@fe870000
(XEN) ipmmu: /soc/mmu@fd800000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@fd800000: found master device /soc/gsx_domd
(XEN) ipmmu: /soc/mmu@fd800000: found master device /soc/gsx_domu
(XEN) ipmmu: /soc/mmu@fd950000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@fd960000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@fd970000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@e6570000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee000000
(XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee020000
(XEN) ipmmu: /soc/mmu@e6570000: found master device 
/soc/dma-controller@e65a0000
(XEN) ipmmu: /soc/mmu@e6570000: found master device 
/soc/dma-controller@e65b0000
(XEN) ipmmu: /soc/mmu@e6570000: found master device 
/soc/dma-controller@e6460000
(XEN) ipmmu: /soc/mmu@e6570000: found master device 
/soc/dma-controller@e6470000
(XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee080100
(XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0a0100
(XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0c0100
(XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0e0100
(XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee080000
(XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0a0000
(XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0c0000
(XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0e0000
(XEN) ipmmu: /soc/mmu@ec670000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@ec670000: found master device 
/soc/dma-controller@ec700000
(XEN) ipmmu: /soc/mmu@ec670000: found master device 
/soc/dma-controller@ec720000
(XEN) ipmmu: /soc/mmu@e6740000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@e6740000: found master device 
/soc/dma-controller@e6700000
(XEN) ipmmu: /soc/mmu@e6740000: found master device /soc/ethernet@e6800000
(XEN) ipmmu: /soc/mmu@e7740000: registered cache IPMMU
(XEN) ipmmu: /soc/mmu@e7740000: found master device 
/soc/dma-controller@e7300000
(XEN) ipmmu: /soc/mmu@e7740000: found master device 
/soc/dma-controller@e7310000
(XEN) ipmmu: /soc/mmu@e7740000: found master device /soc/sd@ee100000
(XEN) ipmmu: /soc/mmu@e7740000: found master device /soc/sd@ee140000
(XEN) ipmmu: /soc/mmu@e7740000: found master device /soc/sd@ee160000
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(XEN) build-id: f7bd09bf8c9d60ec9bf6c5e138e4fa374b4e8419
(XEN) alternatives: Patching with alt table 0000000040111540 -> 
0000000040111930
(XEN) ipmmu: /soc/mmu@e67b0000: d0: Set IPMMU context 0 (pgd 0x77fddf000)
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 000000007a000000
(XEN) Loading ramdisk from boot module @ 0000000076000040
(XEN) Allocating 1:1 mappings totalling 256MB for dom0:
(XEN) BANK[0] 0x00000050000000-0x00000060000000 (256MB)
(XEN) Grant table range: 0x0000077fe00000-0x0000077fe7a000
(XEN) Loading zImage from 000000007a000000 to 
0000000050080000-0000000052080000
(XEN) Loading dom0 initrd from 0000000076000040 to 
0x0000000058200000-0x0000000059c230b7
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x0000000058000000-0x000000005801143d
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 
input to Xen)
(XEN) Freed 292kB init memory.

-------------------------------------------------


As for build without early_printk support...

I should have mentioned about enabling CONFIG_HAS_SCIF option in a cover 
letter (in order to have full UART support). Sorry for that.


Recent Xen already enables it by default [1]

[1] https://patchwork.kernel.org/patch/9848913/


>
>> AFAIR, I tested that branch (ipmmu_v2) before submitting RFC patch
>> series [1] and it was functional.
>>
>> But, I don't quite remember what the BSP version (U-Boot/ARM-TF) I had
>> based on.
> Ok.
>
> Thanks
> -Amit

-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Amit Tomer]

Hi,

>
> Starting kernel ...
>
> - 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) Initrd 0000000076000040-0000000077a230f7
> (XEN) RAM: 0000000048000000 - 00000000bfffffff
> (XEN) RAM: 0000000500000000 - 000000057fffffff
> (XEN) RAM: 0000000600000000 - 000000067fffffff
> (XEN) RAM: 0000000700000000 - 000000077fffffff
> (XEN)
> (XEN) MODULE[0]: 0000000048000000 - 0000000048014080 Device Tree
> (XEN) MODULE[1]: 0000000076000040 - 0000000077a230f7 Ramdisk
> (XEN) MODULE[2]: 000000007a000000 - 000000007c000000 Kernel
> (XEN) MODULE[3]: 000000007c000000 - 000000007c010000 XSM
> (XEN)  RESVD[0]: 0000000048000000 - 0000000048014000
> (XEN)  RESVD[1]: 0000000076000040 - 0000000077a230f7
> (XEN)
> (XEN) Command line: dom0_mem=256M console=dtuart dtuart=serial0
> dom0_max_vcpus=4 bootscrub=0 loglvl=all
> (XEN) Placing Xen at 0x000000077fe00000-0x0000000780000000
> (XEN) Update BOOTMOD_XEN from 0000000078080000-00000000781b2d81 =>
> 000000077fe00000-000000077ff32d81
> (XEN) Domain heap initialised
> (XEN) Booting using Device Tree
> (XEN) Platform: Generic System
> (XEN) Looking for dtuart at "serial0", options ""
> (XEN) Unable to initialize dtuart: -9
> (XEN) Bad console= option 'dtuart'
>   *Xen 4.9.1-pre*
> (XEN) Xen version 4.9.1-pre (otyshchenko@) (aarch64-poky-linux-gcc (GCC)
> 7.3.0) debug=y  Tue Mar  5 20:57:55 EET 2019
> (XEN) Latest ChangeSet: Mon May 8 13:45:21 2017 +0300 git:a438317-dirty
> (XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
> (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: 0000000000001124 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 8 CPUs
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
> (XEN) GICv2 initialization:
> (XEN)         gic_dist_addr=00000000f1010000
> (XEN)         gic_cpu_addr=00000000f1020000
> (XEN)         gic_hyp_addr=00000000f1040000
> (XEN)         gic_vcpu_addr=00000000f1060000
> (XEN)         gic_maintenance_irq=25
> (XEN) GICv2: Adjusting CPU interface base to 0xf102f000
> (XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
> (XEN) XSM Framework v1.0.0 initialized
> (XEN) xsm: Policy len = 0x0000000000010000 start at 0x000000007c000000
> (XEN) Flask: 128 avtab hash slots, 280 rules.
> (XEN) Flask: 128 avtab hash slots, 280 rules.
> (XEN) Flask:  4 users, 3 roles, 38 types, 2 bools
> (XEN) Flask:  12 classes, 280 rules
> (XEN) Flask:  Starting in enforcing mode.
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Allocated console ring of 64 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 00000002 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 2 booted.
> (XEN) Bringing up CPU3
> - CPU 00000003 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 3 booted.
> (XEN) Bringing up CPU4
> - CPU 00000100 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 4 booted.
> (XEN) Bringing up CPU5
> - CPU 00000101 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 5 booted.
> (XEN) Bringing up CPU6
> - CPU 00000102 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 6 booted.
> (XEN) Bringing up CPU7
> - CPU 00000103 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 7 booted.
> (XEN) Brought up 8 CPUs
> (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> (XEN) ipmmu: /soc/mmu@e67b0000: registered root IPMMU
> (XEN) ipmmu: /soc/mmu@e67b0000: disable sharing P2M table between the
> CPU and IPMMU
> (XEN) ipmmu: /soc/mmu@febd0000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef0000
> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef1000
> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef2000
> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef3000
> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/fcp@fea27000
> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/fcp@fea2f000
> (XEN) ipmmu: /soc/mmu@febe0000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef4000
> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef5000
> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef6000
> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef7000
> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/fcp@fea37000
> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/hdmi@fead0000
> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/hdmi@feae0000
> (XEN) ipmmu: /soc/mmu@fe990000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@fe990000: found master device /soc/vspm@fe960000
> (XEN) ipmmu: /soc/mmu@fe990000: found master device /soc/vspm@fe9a0000
> (XEN) ipmmu: /soc/mmu@fe990000: found master device /soc/fdpm@fe940000
> (XEN) ipmmu: /soc/mmu@fe980000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@fe980000: found master device /soc/vspm@fe920000
> (XEN) ipmmu: /soc/mmu@fe980000: found master device /soc/vspm@fe9b0000
> (XEN) ipmmu: /soc/mmu@fe980000: found master device /soc/fdpm@fe944000
> (XEN) ipmmu: /soc/mmu@fe6b0000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@fe6b0000: found master device /soc/imr-lx4@fe880000
> (XEN) ipmmu: /soc/mmu@fe6b0000: found master device /soc/imr-lx4@fe890000
> (XEN) ipmmu: /soc/mmu@fe6b0000: found master device /soc/vcp4@fe90f000
> (XEN) ipmmu: /soc/mmu@fe6f0000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@fe6f0000: found master device /soc/imr-lx4@fe860000
> (XEN) ipmmu: /soc/mmu@fe6f0000: found master device /soc/imr-lx4@fe870000
> (XEN) ipmmu: /soc/mmu@fd800000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@fd800000: found master device /soc/gsx_domd
> (XEN) ipmmu: /soc/mmu@fd800000: found master device /soc/gsx_domu
> (XEN) ipmmu: /soc/mmu@fd950000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@fd960000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@fd970000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@e6570000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee000000
> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee020000
> (XEN) ipmmu: /soc/mmu@e6570000: found master device
> /soc/dma-controller@e65a0000
> (XEN) ipmmu: /soc/mmu@e6570000: found master device
> /soc/dma-controller@e65b0000
> (XEN) ipmmu: /soc/mmu@e6570000: found master device
> /soc/dma-controller@e6460000
> (XEN) ipmmu: /soc/mmu@e6570000: found master device
> /soc/dma-controller@e6470000
> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee080100
> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0a0100
> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0c0100
> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0e0100
> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee080000
> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0a0000
> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0c0000
> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0e0000
> (XEN) ipmmu: /soc/mmu@ec670000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@ec670000: found master device
> /soc/dma-controller@ec700000
> (XEN) ipmmu: /soc/mmu@ec670000: found master device
> /soc/dma-controller@ec720000
> (XEN) ipmmu: /soc/mmu@e6740000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@e6740000: found master device
> /soc/dma-controller@e6700000
> (XEN) ipmmu: /soc/mmu@e6740000: found master device /soc/ethernet@e6800000
> (XEN) ipmmu: /soc/mmu@e7740000: registered cache IPMMU
> (XEN) ipmmu: /soc/mmu@e7740000: found master device
> /soc/dma-controller@e7300000
> (XEN) ipmmu: /soc/mmu@e7740000: found master device
> /soc/dma-controller@e7310000
> (XEN) ipmmu: /soc/mmu@e7740000: found master device /soc/sd@ee100000
> (XEN) ipmmu: /soc/mmu@e7740000: found master device /soc/sd@ee140000

We booted 4.9(non debug build) based on ipmmu_v2 but don't see ipmuu
related logs in
boot logs(is it because its non debug build):

[   62.259664] Starting kernel ...
[   62.262930]
- 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: 0000000048000000 - 000000007fffffff
(XEN) RAM: 0000000500000000 - 000000053fffffff
(XEN) RAM: 0000000600000000 - 000000063fffffff
(XEN) RAM: 0000000700000000 - 000000073fffffff
(XEN)
(XEN) MODULE[0]: 000000007d70f000 - 000000007d722000 Device Tree
(XEN) MODULE[1]: 000000007a000000 - 000000007b800000 Kernel
(XEN)  RESVD[0]: 000000004a000000 - 000000004a013000
(XEN)  RESVD[1]: 000000007d70f000 - 000000007d722000
(XEN)
(XEN) Command line: console=dtuart dom0_mem=512M
(XEN) Placing Xen at 0x000000073fe00000-0x0000000740000000
(XEN) Update BOOTMOD_XEN from 0000000048000000-0000000048108d81 =>
000000073fe00000-000000073ff08d81
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "serial0", options "115200n8"
(XEN) WARNING: UART configuration is not supported
 Xen 4.9.1-pre
(XEN) Xen version 4.9.1-pre (atomar@) (aarch64-linux-gnu-gcc (Linaro
GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=n  Wed Mar 13
13:49:41 I9
(XEN) Latest ChangeSet: Mon May 8 13:45:21 2017 +0300 git:a438317-dirty
(XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
(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: 0000000000001124 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) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv2 initialization:
(XEN)         gic_dist_addr=00000000f1010000
(XEN)         gic_cpu_addr=00000000f1020000
(XEN)         gic_hyp_addr=00000000f1040000
(XEN)         gic_vcpu_addr=00000000f1060000
(XEN)         gic_maintenance_irq=25
(XEN) GICv2: Adjusting CPU interface base to 0xf102f000
(XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 16 KiB.
(XEN) Bringing up CPU1
- CPU 00000001 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Bringing up CPU2
- CPU 00000002 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Bringing up CPU3
- CPU 00000003 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Bringing up CPU4
- CPU 00000100 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Bringing up CPU5
- CPU 00000101 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Bringing up CPU6
- CPU 00000102 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Bringing up CPU7
- CPU 00000103 booting -
- Current EL 00000008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Brought up 8 CPUs
(XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
(XEN) I/O virtualisation disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 000000007a000000
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x00000050000000-0x00000070000000 (512MB)
(XEN) Grant table range: 0x0000073fe00000-0x0000073fe61000
(XEN) Loading zImage from 000000007a000000 to 0000000050080000-0000000051880000
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x0000000058000000-0x0000000058010aed
(XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
(XEN) ....done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 292kB init memory.


Also, this is what we try to get debug build:

#make dist-xen debug=y CONFIG_EARLY_PRINTK=scif,0xe6e88000
XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j16
make -C xen install
make[1]: Entering directory '/scratch/work/xen_work/xen_4.9/xen/xen'
make -f Rules.mk _install
make[2]: Entering directory '/scratch/work/xen_work/xen_4.9/xen/xen'
Rules.mk:11: "You must use 'make menuconfig' to enable/disable debug now."
/scratch/work/xen_work/xen_4.9/xen/xen/arch/arm/Rules.mk:85: ***
CONFIG_EARLY_PRINTK enabled for non-debug build.  Stop.
make[2]: Leaving directory '/scratch/work/xen_work/xen_4.9/xen/xen'
Makefile:45: recipe for target 'install' failed
make[1]: *** [install] Error 2
make[1]: Leaving directory '/scratch/work/xen_work/xen_4.9/xen/xen'
Makefile:122: recipe for target 'install-xen' failed
make: *** [install-xen] Error 2

Thanks
-Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: XEN on R-CAR H3

[Oleksandr]

On 13.03.19 14:41, Amit Tomer wrote:
> Hi,

Hi


>
>> Starting kernel ...
>>
>> - 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) Initrd 0000000076000040-0000000077a230f7
>> (XEN) RAM: 0000000048000000 - 00000000bfffffff
>> (XEN) RAM: 0000000500000000 - 000000057fffffff
>> (XEN) RAM: 0000000600000000 - 000000067fffffff
>> (XEN) RAM: 0000000700000000 - 000000077fffffff
>> (XEN)
>> (XEN) MODULE[0]: 0000000048000000 - 0000000048014080 Device Tree
>> (XEN) MODULE[1]: 0000000076000040 - 0000000077a230f7 Ramdisk
>> (XEN) MODULE[2]: 000000007a000000 - 000000007c000000 Kernel
>> (XEN) MODULE[3]: 000000007c000000 - 000000007c010000 XSM
>> (XEN)  RESVD[0]: 0000000048000000 - 0000000048014000
>> (XEN)  RESVD[1]: 0000000076000040 - 0000000077a230f7
>> (XEN)
>> (XEN) Command line: dom0_mem=256M console=dtuart dtuart=serial0
>> dom0_max_vcpus=4 bootscrub=0 loglvl=all
>> (XEN) Placing Xen at 0x000000077fe00000-0x0000000780000000
>> (XEN) Update BOOTMOD_XEN from 0000000078080000-00000000781b2d81 =>
>> 000000077fe00000-000000077ff32d81
>> (XEN) Domain heap initialised
>> (XEN) Booting using Device Tree
>> (XEN) Platform: Generic System
>> (XEN) Looking for dtuart at "serial0", options ""
>> (XEN) Unable to initialize dtuart: -9
>> (XEN) Bad console= option 'dtuart'
>>    *Xen 4.9.1-pre*
>> (XEN) Xen version 4.9.1-pre (otyshchenko@) (aarch64-poky-linux-gcc (GCC)
>> 7.3.0) debug=y  Tue Mar  5 20:57:55 EET 2019
>> (XEN) Latest ChangeSet: Mon May 8 13:45:21 2017 +0300 git:a438317-dirty
>> (XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
>> (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: 0000000000001124 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 8 CPUs
>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
>> (XEN) GICv2 initialization:
>> (XEN)         gic_dist_addr=00000000f1010000
>> (XEN)         gic_cpu_addr=00000000f1020000
>> (XEN)         gic_hyp_addr=00000000f1040000
>> (XEN)         gic_vcpu_addr=00000000f1060000
>> (XEN)         gic_maintenance_irq=25
>> (XEN) GICv2: Adjusting CPU interface base to 0xf102f000
>> (XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
>> (XEN) XSM Framework v1.0.0 initialized
>> (XEN) xsm: Policy len = 0x0000000000010000 start at 0x000000007c000000
>> (XEN) Flask: 128 avtab hash slots, 280 rules.
>> (XEN) Flask: 128 avtab hash slots, 280 rules.
>> (XEN) Flask:  4 users, 3 roles, 38 types, 2 bools
>> (XEN) Flask:  12 classes, 280 rules
>> (XEN) Flask:  Starting in enforcing mode.
>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> (XEN) Allocated console ring of 64 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 00000002 booting -
>> - Current EL 00000008 -
>> - Xen starting at EL2 -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> (XEN) CPU 2 booted.
>> (XEN) Bringing up CPU3
>> - CPU 00000003 booting -
>> - Current EL 00000008 -
>> - Xen starting at EL2 -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> (XEN) CPU 3 booted.
>> (XEN) Bringing up CPU4
>> - CPU 00000100 booting -
>> - Current EL 00000008 -
>> - Xen starting at EL2 -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> (XEN) CPU 4 booted.
>> (XEN) Bringing up CPU5
>> - CPU 00000101 booting -
>> - Current EL 00000008 -
>> - Xen starting at EL2 -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> (XEN) CPU 5 booted.
>> (XEN) Bringing up CPU6
>> - CPU 00000102 booting -
>> - Current EL 00000008 -
>> - Xen starting at EL2 -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> (XEN) CPU 6 booted.
>> (XEN) Bringing up CPU7
>> - CPU 00000103 booting -
>> - Current EL 00000008 -
>> - Xen starting at EL2 -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> (XEN) CPU 7 booted.
>> (XEN) Brought up 8 CPUs
>> (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
>> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
>> (XEN) ipmmu: /soc/mmu@e67b0000: registered root IPMMU
>> (XEN) ipmmu: /soc/mmu@e67b0000: disable sharing P2M table between the
>> CPU and IPMMU
>> (XEN) ipmmu: /soc/mmu@febd0000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef0000
>> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef1000
>> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef2000
>> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/video@e6ef3000
>> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/fcp@fea27000
>> (XEN) ipmmu: /soc/mmu@febd0000: found master device /soc/fcp@fea2f000
>> (XEN) ipmmu: /soc/mmu@febe0000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef4000
>> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef5000
>> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef6000
>> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/video@e6ef7000
>> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/fcp@fea37000
>> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/hdmi@fead0000
>> (XEN) ipmmu: /soc/mmu@febe0000: found master device /soc/hdmi@feae0000
>> (XEN) ipmmu: /soc/mmu@fe990000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@fe990000: found master device /soc/vspm@fe960000
>> (XEN) ipmmu: /soc/mmu@fe990000: found master device /soc/vspm@fe9a0000
>> (XEN) ipmmu: /soc/mmu@fe990000: found master device /soc/fdpm@fe940000
>> (XEN) ipmmu: /soc/mmu@fe980000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@fe980000: found master device /soc/vspm@fe920000
>> (XEN) ipmmu: /soc/mmu@fe980000: found master device /soc/vspm@fe9b0000
>> (XEN) ipmmu: /soc/mmu@fe980000: found master device /soc/fdpm@fe944000
>> (XEN) ipmmu: /soc/mmu@fe6b0000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@fe6b0000: found master device /soc/imr-lx4@fe880000
>> (XEN) ipmmu: /soc/mmu@fe6b0000: found master device /soc/imr-lx4@fe890000
>> (XEN) ipmmu: /soc/mmu@fe6b0000: found master device /soc/vcp4@fe90f000
>> (XEN) ipmmu: /soc/mmu@fe6f0000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@fe6f0000: found master device /soc/imr-lx4@fe860000
>> (XEN) ipmmu: /soc/mmu@fe6f0000: found master device /soc/imr-lx4@fe870000
>> (XEN) ipmmu: /soc/mmu@fd800000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@fd800000: found master device /soc/gsx_domd
>> (XEN) ipmmu: /soc/mmu@fd800000: found master device /soc/gsx_domu
>> (XEN) ipmmu: /soc/mmu@fd950000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@fd960000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@fd970000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@e6570000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee000000
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee020000
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device
>> /soc/dma-controller@e65a0000
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device
>> /soc/dma-controller@e65b0000
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device
>> /soc/dma-controller@e6460000
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device
>> /soc/dma-controller@e6470000
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee080100
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0a0100
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0c0100
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0e0100
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee080000
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0a0000
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0c0000
>> (XEN) ipmmu: /soc/mmu@e6570000: found master device /soc/usb@ee0e0000
>> (XEN) ipmmu: /soc/mmu@ec670000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@ec670000: found master device
>> /soc/dma-controller@ec700000
>> (XEN) ipmmu: /soc/mmu@ec670000: found master device
>> /soc/dma-controller@ec720000
>> (XEN) ipmmu: /soc/mmu@e6740000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@e6740000: found master device
>> /soc/dma-controller@e6700000
>> (XEN) ipmmu: /soc/mmu@e6740000: found master device /soc/ethernet@e6800000
>> (XEN) ipmmu: /soc/mmu@e7740000: registered cache IPMMU
>> (XEN) ipmmu: /soc/mmu@e7740000: found master device
>> /soc/dma-controller@e7300000
>> (XEN) ipmmu: /soc/mmu@e7740000: found master device
>> /soc/dma-controller@e7310000
>> (XEN) ipmmu: /soc/mmu@e7740000: found master device /soc/sd@ee100000
>> (XEN) ipmmu: /soc/mmu@e7740000: found master device /soc/sd@ee140000
> We booted 4.9(non debug build) based on ipmmu_v2 but don't see ipmuu
> related logs in
> boot logs(is it because its non debug build):

I have just tried "non debug" build, but with "loglvl=all" in bootargs. 
With such configuration I see IPMMU related logs.


 From the following string "(XEN) I/O virtualisation disabled" in your 
log, I assume that IPMMU hasn't been registered.

Probably, you have IPMMU devices disabled/removed in your host 
device-tree and Xen couldn't pick them up.

If this is a reason, then you need to enable them ("IPMMU root" device 
and required "IPMMU cache(s)") and tie required bus masters (DMA 
devices) to "IPMMU caches".

For example, H3 case:

/* root */

&ipmmu_mm {
     status = "okay";
};

/* cache */

&ipmmu_ds0 {
     status = "okay";
};

/* DMA device */

&avb {
     iommus = <&ipmmu_ds0 16>;
};


>
> [   62.259664] Starting kernel ...
> [   62.262930]
> - 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: 0000000048000000 - 000000007fffffff
> (XEN) RAM: 0000000500000000 - 000000053fffffff
> (XEN) RAM: 0000000600000000 - 000000063fffffff
> (XEN) RAM: 0000000700000000 - 000000073fffffff
> (XEN)
> (XEN) MODULE[0]: 000000007d70f000 - 000000007d722000 Device Tree
> (XEN) MODULE[1]: 000000007a000000 - 000000007b800000 Kernel
> (XEN)  RESVD[0]: 000000004a000000 - 000000004a013000
> (XEN)  RESVD[1]: 000000007d70f000 - 000000007d722000
> (XEN)
> (XEN) Command line: console=dtuart dom0_mem=512M
> (XEN) Placing Xen at 0x000000073fe00000-0x0000000740000000
> (XEN) Update BOOTMOD_XEN from 0000000048000000-0000000048108d81 =>
> 000000073fe00000-000000073ff08d81
> (XEN) Domain heap initialised
> (XEN) Booting using Device Tree
> (XEN) Taking dtuart configuration from /chosen/stdout-path
> (XEN) Looking for dtuart at "serial0", options "115200n8"
> (XEN) WARNING: UART configuration is not supported
>   Xen 4.9.1-pre
> (XEN) Xen version 4.9.1-pre (atomar@) (aarch64-linux-gnu-gcc (Linaro
> GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
> d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=n  Wed Mar 13
> 13:49:41 I9
> (XEN) Latest ChangeSet: Mon May 8 13:45:21 2017 +0300 git:a438317-dirty
> (XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
> (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: 0000000000001124 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) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
> (XEN) GICv2 initialization:
> (XEN)         gic_dist_addr=00000000f1010000
> (XEN)         gic_cpu_addr=00000000f1020000
> (XEN)         gic_hyp_addr=00000000f1040000
> (XEN)         gic_vcpu_addr=00000000f1060000
> (XEN)         gic_maintenance_irq=25
> (XEN) GICv2: Adjusting CPU interface base to 0xf102f000
> (XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Allocated console ring of 16 KiB.
> (XEN) Bringing up CPU1
> - CPU 00000001 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Bringing up CPU2
> - CPU 00000002 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Bringing up CPU3
> - CPU 00000003 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Bringing up CPU4
> - CPU 00000100 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Bringing up CPU5
> - CPU 00000101 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Bringing up CPU6
> - CPU 00000102 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Bringing up CPU7
> - CPU 00000103 booting -
> - Current EL 00000008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Brought up 8 CPUs
> (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> (XEN) I/O virtualisation disabled
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading kernel from boot module @ 000000007a000000
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x00000050000000-0x00000070000000 (512MB)
> (XEN) Grant table range: 0x0000073fe00000-0x0000073fe61000
> (XEN) Loading zImage from 000000007a000000 to 0000000050080000-0000000051880000
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading dom0 DTB to 0x0000000058000000-0x0000000058010aed
> (XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
> (XEN) ....done.
> (XEN) Initial low memory virq threshold set at 0x4000 pages.
> (XEN) Std. Loglevel: Errors and warnings
> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to Xen)
> (XEN) Freed 292kB init memory.
>
>
> Also, this is what we try to get debug build:
>
> #make dist-xen debug=y CONFIG_EARLY_PRINTK=scif,0xe6e88000
> XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j16
> make -C xen install
> make[1]: Entering directory '/scratch/work/xen_work/xen_4.9/xen/xen'
> make -f Rules.mk _install
> make[2]: Entering directory '/scratch/work/xen_work/xen_4.9/xen/xen'
> Rules.mk:11: "You must use 'make menuconfig' to enable/disable debug now."
> /scratch/work/xen_work/xen_4.9/xen/xen/arch/arm/Rules.mk:85: ***
> CONFIG_EARLY_PRINTK enabled for non-debug build.  Stop.
> make[2]: Leaving directory '/scratch/work/xen_work/xen_4.9/xen/xen'
> Makefile:45: recipe for target 'install' failed
> make[1]: *** [install] Error 2
> make[1]: Leaving directory '/scratch/work/xen_work/xen_4.9/xen/xen'
> Makefile:122: recipe for target 'install-xen' failed
> make: *** [install-xen] Error 2
>
> Thanks
> -Amit

-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel