* XEN on R-CAR H3 @ 2019-02-06 14:41 Amit Tomer 2019-02-06 15:03 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-02-06 14:41 UTC (permalink / raw) To: xen-devel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-06 14:41 XEN on R-CAR H3 Amit Tomer @ 2019-02-06 15:03 ` Oleksandr 2019-02-06 15:18 ` Amit Tomer 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-06 15:03 UTC (permalink / raw) To: Amit Tomer, xen-devel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-06 15:03 ` Oleksandr @ 2019-02-06 15:18 ` Amit Tomer 2019-02-08 18:21 ` Amit Tomer 0 siblings, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-02-06 15:18 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-06 15:18 ` Amit Tomer @ 2019-02-08 18:21 ` Amit Tomer 2019-02-09 16:48 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-02-08 18:21 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-08 18:21 ` Amit Tomer @ 2019-02-09 16:48 ` Oleksandr 2019-02-15 14:17 ` Amit Tomer 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-09 16:48 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-09 16:48 ` Oleksandr @ 2019-02-15 14:17 ` Amit Tomer 2019-02-15 19:51 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-02-15 14:17 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-15 14:17 ` Amit Tomer @ 2019-02-15 19:51 ` Oleksandr 2019-02-18 12:53 ` Amit Tomer 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-15 19:51 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-15 19:51 ` Oleksandr @ 2019-02-18 12:53 ` Amit Tomer 2019-02-18 20:00 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-02-18 12:53 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-18 12:53 ` Amit Tomer @ 2019-02-18 20:00 ` Oleksandr 2019-02-19 16:46 ` Amit Tomer 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-18 20:00 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-18 20:00 ` Oleksandr @ 2019-02-19 16:46 ` Amit Tomer 2019-02-20 18:13 ` Oleksandr 2019-02-20 20:13 ` Julien Grall 0 siblings, 2 replies; 34+ messages in thread From: Amit Tomer @ 2019-02-19 16:46 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-19 16:46 ` Amit Tomer @ 2019-02-20 18:13 ` Oleksandr 2019-02-20 18:31 ` Amit Tomer 2019-02-20 20:13 ` Julien Grall 1 sibling, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-20 18:13 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-20 18:13 ` Oleksandr @ 2019-02-20 18:31 ` Amit Tomer 0 siblings, 0 replies; 34+ messages in thread From: Amit Tomer @ 2019-02-20 18:31 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-19 16:46 ` Amit Tomer 2019-02-20 18:13 ` Oleksandr @ 2019-02-20 20:13 ` Julien Grall 2019-02-20 21:28 ` Oleksandr Tyshchenko 2019-02-21 18:15 ` Amit Tomer 1 sibling, 2 replies; 34+ messages in thread From: Julien Grall @ 2019-02-20 20:13 UTC (permalink / raw) To: Amit Tomer, Oleksandr; +Cc: xen-devel, andrii_chepurnyi 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-20 20:13 ` Julien Grall @ 2019-02-20 21:28 ` Oleksandr Tyshchenko 2019-02-21 10:11 ` Julien Grall 2019-02-21 18:20 ` Amit Tomer 2019-02-21 18:15 ` Amit Tomer 1 sibling, 2 replies; 34+ messages in thread From: Oleksandr Tyshchenko @ 2019-02-20 21:28 UTC (permalink / raw) To: Julien Grall; +Cc: xen-devel, andrii_chepurnyi, amittomer25 [-- 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-20 21:28 ` Oleksandr Tyshchenko @ 2019-02-21 10:11 ` Julien Grall 2019-02-21 19:28 ` Oleksandr 2019-02-21 18:20 ` Amit Tomer 1 sibling, 1 reply; 34+ messages in thread From: Julien Grall @ 2019-02-21 10:11 UTC (permalink / raw) To: Oleksandr Tyshchenko; +Cc: xen-devel, nd, andrii_chepurnyi, amittomer25 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-21 10:11 ` Julien Grall @ 2019-02-21 19:28 ` Oleksandr 2019-02-25 14:43 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-21 19:28 UTC (permalink / raw) To: Julien Grall; +Cc: xen-devel, nd, andrii_chepurnyi, amittomer25 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-21 19:28 ` Oleksandr @ 2019-02-25 14:43 ` Oleksandr 2019-02-25 23:23 ` Julien Grall 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-25 14:43 UTC (permalink / raw) To: Julien Grall; +Cc: xen-devel, nd, andrii_chepurnyi, amittomer25 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-25 14:43 ` Oleksandr @ 2019-02-25 23:23 ` Julien Grall 2019-02-26 18:09 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Julien Grall @ 2019-02-25 23:23 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel, nd, andrii_chepurnyi, amittomer25 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-25 23:23 ` Julien Grall @ 2019-02-26 18:09 ` Oleksandr 0 siblings, 0 replies; 34+ messages in thread From: Oleksandr @ 2019-02-26 18:09 UTC (permalink / raw) To: Julien Grall; +Cc: xen-devel, nd, andrii_chepurnyi, amittomer25 > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-20 21:28 ` Oleksandr Tyshchenko 2019-02-21 10:11 ` Julien Grall @ 2019-02-21 18:20 ` Amit Tomer 2019-02-21 18:44 ` Oleksandr 1 sibling, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-02-21 18:20 UTC (permalink / raw) To: Oleksandr Tyshchenko; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-21 18:20 ` Amit Tomer @ 2019-02-21 18:44 ` Oleksandr 2019-02-22 19:15 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-21 18:44 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-21 18:44 ` Oleksandr @ 2019-02-22 19:15 ` Oleksandr 2019-02-22 20:08 ` Amit Tomer 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-22 19:15 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-22 19:15 ` Oleksandr @ 2019-02-22 20:08 ` Amit Tomer 2019-02-23 13:05 ` Amit Tomer 0 siblings, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-02-22 20:08 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-22 20:08 ` Amit Tomer @ 2019-02-23 13:05 ` Amit Tomer 2019-02-25 13:12 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-02-23 13:05 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-23 13:05 ` Amit Tomer @ 2019-02-25 13:12 ` Oleksandr 2019-02-27 20:03 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-25 13:12 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-25 13:12 ` Oleksandr @ 2019-02-27 20:03 ` Oleksandr 2019-03-05 16:50 ` Amit Tomer 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-02-27 20:03 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-27 20:03 ` Oleksandr @ 2019-03-05 16:50 ` Amit Tomer 2019-03-05 18:07 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-03-05 16:50 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-03-05 16:50 ` Amit Tomer @ 2019-03-05 18:07 ` Oleksandr 2019-03-05 18:10 ` Amit Tomer 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-03-05 18:07 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-03-05 18:07 ` Oleksandr @ 2019-03-05 18:10 ` Amit Tomer 2019-03-05 19:40 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-03-05 18:10 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-03-05 18:10 ` Amit Tomer @ 2019-03-05 19:40 ` Oleksandr 2019-03-13 12:41 ` Amit Tomer 0 siblings, 1 reply; 34+ messages in thread From: Oleksandr @ 2019-03-05 19:40 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-03-05 19:40 ` Oleksandr @ 2019-03-13 12:41 ` Amit Tomer 2019-03-15 18:50 ` Oleksandr 0 siblings, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-03-13 12:41 UTC (permalink / raw) To: Oleksandr; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-03-13 12:41 ` Amit Tomer @ 2019-03-15 18:50 ` Oleksandr 0 siblings, 0 replies; 34+ messages in thread From: Oleksandr @ 2019-03-15 18:50 UTC (permalink / raw) To: Amit Tomer; +Cc: xen-devel, Julien Grall, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-20 20:13 ` Julien Grall 2019-02-20 21:28 ` Oleksandr Tyshchenko @ 2019-02-21 18:15 ` Amit Tomer 2019-02-27 11:00 ` Julien Grall 1 sibling, 1 reply; 34+ messages in thread From: Amit Tomer @ 2019-02-21 18:15 UTC (permalink / raw) To: Julien Grall; +Cc: Oleksandr, xen-devel, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: XEN on R-CAR H3 2019-02-21 18:15 ` Amit Tomer @ 2019-02-27 11:00 ` Julien Grall 0 siblings, 0 replies; 34+ messages in thread From: Julien Grall @ 2019-02-27 11:00 UTC (permalink / raw) To: Amit Tomer; +Cc: Oleksandr, xen-devel, andrii_chepurnyi 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2019-03-15 18:50 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-06 14:41 XEN on R-CAR H3 Amit Tomer 2019-02-06 15:03 ` Oleksandr 2019-02-06 15:18 ` Amit Tomer 2019-02-08 18:21 ` Amit Tomer 2019-02-09 16:48 ` Oleksandr 2019-02-15 14:17 ` Amit Tomer 2019-02-15 19:51 ` Oleksandr 2019-02-18 12:53 ` Amit Tomer 2019-02-18 20:00 ` Oleksandr 2019-02-19 16:46 ` Amit Tomer 2019-02-20 18:13 ` Oleksandr 2019-02-20 18:31 ` Amit Tomer 2019-02-20 20:13 ` Julien Grall 2019-02-20 21:28 ` Oleksandr Tyshchenko 2019-02-21 10:11 ` Julien Grall 2019-02-21 19:28 ` Oleksandr 2019-02-25 14:43 ` Oleksandr 2019-02-25 23:23 ` Julien Grall 2019-02-26 18:09 ` Oleksandr 2019-02-21 18:20 ` Amit Tomer 2019-02-21 18:44 ` Oleksandr 2019-02-22 19:15 ` Oleksandr 2019-02-22 20:08 ` Amit Tomer 2019-02-23 13:05 ` Amit Tomer 2019-02-25 13:12 ` Oleksandr 2019-02-27 20:03 ` Oleksandr 2019-03-05 16:50 ` Amit Tomer 2019-03-05 18:07 ` Oleksandr 2019-03-05 18:10 ` Amit Tomer 2019-03-05 19:40 ` Oleksandr 2019-03-13 12:41 ` Amit Tomer 2019-03-15 18:50 ` Oleksandr 2019-02-21 18:15 ` Amit Tomer 2019-02-27 11:00 ` Julien Grall
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.