- l4-hackers - example.com Site

l4re + rpi4 + mmc + vm + net
by Matthieu Fatrez 19 Sep '21

19 Sep '21

Hello l4-hackers, I try to run a vm with l4re on a RPI4b with this files bellow, but I don't know how to find the root device to finalize the boot process. I haven't played on the network part yet, but if you have any advice on the subject as well, I'm a taker. Help needed please. Thanks. vm_hw.vbus ------8<------------------------------------------------------------------------------------------------ Io.add_vbusses { vm_hw = Io.Vi.System_bus(function() MMC = wrap(Io.system_bus().mmc); end); } ------8<------------------------------------------------------------------------------------------------ io.cfg ------8<------------------------------------------------------------------------------------------------ local Res = Io.Res local Hw = Io.Hw local add_children = Io.Dt.add_children add_children(Io.system_bus(), function() mmc = Hw.Device(function() compatible = { "brcm,bcm2835-mmc" }; Resource.reg0 = Res.mmio(0xfe300000, 0xfe3000FF); Resource.irq0 = Res.irq(0x7e + 32); Property.flags = Io.Hw_device_DF_dma_supported; end) end) ------8<------------------------------------------------------------------------------------------------ mmc.dts ------8<------------------------------------------------------------------------------------------------ /dts-v1/; /include/ "virt-arm_virt-64.dts" / { mmc@fe300000 { compatible = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci"; reg = <0xfe300000 0x100>; interrupts = <0x0 0x7e 0x4>; clocks = <0x3 0x1c>; dmas = <0xa 0xb>; dma-names = "rx-tx"; brcm,overclock-50 = <0x0>; status = "disabled"; pinctrl-names = "default"; pinctrl-0 = <0x19>; bus-width = <0x4>; phandle = <0x2d>; }; }; ------8<------------------------------------------------------------------------------------------------ mfa.cfg ------8<------------------------------------------------------------------------------------------------ local L4 = require "L4"; local l = L4.default_loader; vbus_l4linux = l:new_channel(); -- Start io & flash memory l:start({ caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0), icu = L4.Env.icu, vm_hw = vbus_l4linux:svr() }, log = {"IO", "y"} }, "rom/io rom/io.cfg rom/vm_hw.vbus -vvvvvv"); l:startv({ caps = { ram = L4.Env.user_factory:create( L4.Proto.Dataspace, 256 * 1024 * 1024, L4.Mem_alloc_flags.Continuous | L4.Mem_alloc_flags.Pinned | L4.Mem_alloc_flags.Super_pages, 21):m("rws"); vbus = vbus_l4linux; }, log = L4.Env.log:m("rws") }, "rom/uvmm", "-v", "--kernel", "rom/Image.gz", "--ramdisk", "rom/ramdisk-armv8-64.rd", "--dtb", "rom/mmc.dtb", "--cmdline", "console=hvc0 ramdisk_size=10000 root=/dev/mmcblkp3 rw"); ------8<------------------------------------------------------------------------------------------------ in modules.list ------8<------------------------------------------------------------------------------------------------ entry mfa roottask moe rom/mfa.cfg module l4re module hello module uvmm module ned module mfa.cfg module uvmm module cons module dtb/virt-arm_virt-64.dtb module mmc.dtb module[shell] echo $SRC_BASE_ABS/pkg/uvmm/configs/vmm.lua module ramdisk-armv8-64.rd module[uncompress] Image.gz module io module io.cfg module vm_hw.vbus ------8<------------------------------------------------------------------------------------------------ Log from console ------8<------------------------------------------------------------------------------------------------ ## Starting application at 0x010000 L4 Bootstrapper Build: #29 Sat Sep 18 16:38:05 CEST 2021, 10.2.1 20210110 Raspberry Pi Model 4B, Rev 1.4, 8192MB, SoC BCM2711 [d03114] Warranty intact, OTP reading allowed, OTP programming allowed, Overvoltage allowed RAM: 0000000000000000 - 000000003b3fffff: 970752kB RAM: 0000000040000000 - 00000000fbffffff: 3080192kB RAM: 0000000100000000 - 00000001ffffffff: 4194304kB Total RAM: 8052MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 18 modules behind 1100000 moving module 17 { 39dc000-39dc066 } -> { 3ac1000-3ac1066 } [103] moving module 16 { 39db000-39db16e } -> { 3ac0000-3ac016e } [367] moving module 15 { 3796000-39da99f } -> { 387b000-3abf99f } [2378144] moving module 14 { 16d9000-37959ff } -> { 17be000-387a9ff } [34327040] moving module 13 { 1359000-16d8fff } -> { 143e000-17bdfff } [3670016] moving module 12 { 1358000-1358dbf } -> { 143d000-143ddbf } [3520] moving module 11 { 1357000-1357756 } -> { 143c000-143c756 } [1879] moving module 10 { 1356000-13565e9 } -> { 143b000-143b5e9 } [1514] moving module 09 { 130a000-1355ecf } -> { 13ef000-143aecf } [310992] moving module 08 { 1254000-130962f } -> { 1339000-13ee62f } [742960] moving module 07 { 1253000-1253386 } -> { 1338000-1338386 } [903] moving module 06 { 11d3000-1252a97 } -> { 12b8000-1337a97 } [522904] moving module 05 { 111d000-11d262f } -> { 1202000-12b762f } [742960] moving module 04 { 10f0000-111c9e7 } -> { 11d5000-12019e7 } [182760] moving module 03 { 10d2000-10ef957 } -> { 11b7000-11d4957 } [121176] moving module 02 { 109e000-10d13d7 } -> { 1183000-11b63d7 } [209880] moving module 01 { 1098000-109dd6f } -> { 117d000-1182d6f } [23920] moving module 00 { 101b000-1097387 } -> { 1100000-117c387 } [508808] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 3000 Regions of list 'regions' [ 0, fff] { 1000} Arch mpspin [ 1000, 8dfff] { 8d000} Kern fiasco [ 8e000, 8e347] { 348} Root mbi_rt [ 100000, 10a46f] { a470} Sigma0 sigma0 [ 140000, 170cab] { 30cac} Root moe [ 171cb0, 17eed7] { d228} Root moe [ 1000000, 101900b] { 1900c} Boot bootstrap [ 10000e8, 100011b] { 34} Root cpu_boot [ 101a1a4, 101ae49] { ca6} Boot modinfo [ 11b7000, 3ac1066] { 290a067} Root Module found kernel options (via ELF) at 4000 Sigma0 config ip:00100474 sp:00000000 Roottask config ip:00141584 sp:00000000 Starting kernel fiasco at 000016d0 Hello from Startup::stage2 Number of IRQs available at this GIC: 256 FPU: Initialize ARM generic timer: freq=54000000 interval=54000 cnt=1197663468 SERIAL ESC: allocated IRQ 125 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: unknown compiled with gcc 10.2.1 20210110 for RPi4 (Broadcom 2711) [] Build: #1 Sat Sep 18 00:56:20 CEST 2021 Allocate ARM PPI 25 to virtual 0 Allocate ARM PPI 27 to virtual 1 Allocate ARM PPI 25 to virtual 0 Allocate ARM PPI 27 to virtual 1 Allocate ARM PPI 25 to virtual 0 Cache config: ON Allocate ARM PPI 27 to virtual 1 ID_PFR[01]: 00002222 00000000Calibrating timer loop... Cache config: ON Allocate ARM PPI 25 to virtual 0 done. Allocate ARM PPI 27 to virtual 1 MDB: use page size: 30 Cache config: ON ID_PFR[01]: 00002222 00000000MDB: use page size: 21 ID_[DA]FR0: 10305106 00000000 ID_[DA]FR0: 10305106 00000000 ID_MMFR[04]: 00001124 00000000 00000000 00000000 ID_MMFR[04]: 00001124 00000000 00000000 00000000 MDB: use page size: 12 ID_PFR[01]: 00002222 00000000S ID_[DA]FR0: 10305106 00000000 IID_MMFR[04]: 00001124 00000000 00000000 00000000 GMA0: Hello! KIP @ 3000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:RWX:8e000;8efff] [0:RWX:8f000;fffff] [0:RWX:10b000;13ffff] [4:R-X:140000;170fff] [4:RW-:171000;17efff] [0:RWX:17f000;ffffff] [4:---:1000000;1000fff] [0:RWX:1001000;11b6fff] [4:RWX:11b7000;3ac1fff] [0:RWX:3ac2000;3b3fffff] [0:RWX:40000000;fbffffff] [0:RWX:100000000;1feffffff] IOMEM:---------------------- [0:RW-:0;fff] [0:RW-:3b400000;3fffffff] [0:RW-:fc000000;ffffffff] [0:RW-:200000000;ffffffffffffffff] MOE: Hello world MOE: found 8185968 KByte free memory MOE: found RAM from 8e000 to 1ff000000 MOE: allocated 8175 KByte for the page array @0x17f000 MOE: virtual user address space [0-7fffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [11b7000-11d4958] [C:107000] l4re BOOTFS: [11d5000-12019e8] [C:109000] hello BOOTFS: [1202000-12b7630] [C:10b000] uvmm BOOTFS: [12b8000-1337a98] [C:10d000] ned BOOTFS: [1338000-1338387] [C:10f000] mfa.cfg BOOTFS: [1339000-13ee630] [C:111000] uvmm BOOTFS: [13ef000-143aed0] [C:112000] cons BOOTFS: [143b000-143b5ea] [C:114000] virt-arm_virt-64.dtb BOOTFS: [143c000-143c757] [C:116000] mmc.dtb BOOTFS: [143d000-143ddc0] [C:118000] vmm.lua BOOTFS: [143e000-17be000] [C:11a000] ramdisk-armv8-64.rd BOOTFS: [17be000-387aa00] [C:11c000] Image.gz BOOTFS: [387b000-3abf9a0] [C:11e000] io BOOTFS: [3ac0000-3ac016f] [C:120000] io.cfg BOOTFS: [3ac1000-3ac1067] [C:122000] vm_hw.vbus MOE: cmdline: moe rom/mfa.cfg MOE: Starting: rom/ned rom/mfa.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/mfa.cfg' IO | Io service IO | Verboseness level: 7 IO | unused physical memory space: IO | [0000003b400000-0000003fffffff] IO | [000000fc000000-000000ffffffff] IO | [00000200000000-ffffffffffffffff] IO | no 'iommu' capability found, using CPU-phys for DMA VMM[]: Created VCPU 0 @ 17000 VMM[GIC]: create ARM GICv2 IO | Loading: config 'rom/io.cfg' IO | Loading: config 'rom/vm_hw.vbus' IO | Add IRQ resources to vbus: IRQ [0000000000009e-0000000000009e 1] none (align=0 flags=1) IO | vm_hw: [N12_GLOBAL__N_112Virtual_sbusE] IO | Resources: ==== start ==== IO | Resources: ===== end ===== IO | L4ICU: [N2Vi6Sw_icuE] IO | Resources: ==== start ==== IO | Resources: ===== end ===== IO | MMC: [N2Vi9Proxy_devE] IO | Resources: ==== start ==== IO | IOMEM [000000fe300000-000000fe3000ff 100] 32-bit non-pref (align=ff flags=2) IO | IRQ [0000000000009e-0000000000009e 1] none (align=0 flags=1) IO | DMADOM [00000000000000-00000000000000 1] (align=0 flags=6) IO | Resources: ===== end ===== IO | Real Hardware ----------------------------------- IO | System Bus: IO | Resources: ==== start ==== IO | DMADOM [00000000000000-00000000000000 1] (align=0 flags=6) IO | Resources: ===== end ===== IO | mmc: IO | compatible= { "brcm,bcm2835-mmc" } IO | Clients: ===== start ==== IO | MMC: [N2Vi9Proxy_devE] IO | Clients: ===== end ==== IO | Resources: ==== start ==== IO | IOMEM [000000fe300000-000000fe3000ff 100] 32-bit non-pref (align=ff flags=2) IO | IRQ [0000000000009e-0000000000009e 1] none (align=0 flags=1) IO | DMADOM [00000000000000-00000000000000 1] (align=0 flags=6) IO | Resources: ===== end ===== IO | warning: could not register control interface at cap 'platform_ctl' IO | Ready. Waiting for request. VMM[main]: Hello out there. VMM[ram]: RAM: @ 0x3c00000 size=0x10000000 (ci) VMM[ram]: RAM: VMM mapping @ 0x2000000 size=0x10000000 VMM[ram]: RAM: VM offset=0xfffffffffe400000 VMM[main]: Loading kernel... VMM[file]: load: @ 0x3c00000 VMM[file]: copy in: to offset 0x0-0x20bc9ff VMM[main]: Loading ram disk... VMM[ram]: load: rom/ramdisk-armv8-64.rd -> 0x13800000 VMM[file]: load: @ 0x13800000 VMM[file]: copy in: to offset 0xfc00000-0xff7ffff VMM[main]: Loaded ramdisk image rom/ramdisk-armv8-64.rd to 13800000 (size: 00380000) VMM[]: Create virtual console VMM[guest]: New mmio mapping: @ f1040000 10000 VMM[GIC]: GICC virtualization only supports sizes up to 0x1000, adjusting device tree node VMM[GIC]: GIC interrupt-controller.reg update: Adjusting GICC size from 20000 to 1000 VMM[guest]: New mmio mapping: @ f1060000 1000 VMM[guest]: New mmio mapping: @ f1120000 100 VMM[]: virtio_net(a)10000.l4vmm,virtiocap: capability net is invalid. VMM[vm]: Device creation for virtual device virtio_net@10000 failed. Disabling device. VMM[Timer]: Guest timer frequency is 54000000 using (1/54), (9942053/29) to calculate timeouts VMM[psci]: Register PSCI device: hvc mode VMM[ioproxy]: Adding MMIO resource MMC.reg0 : [0xfe300000 - 0xfe3000ff] VMM[ioproxy]: Registering IRQ resource MMC.irq0 : 0x9e VMM[ram]: Cleaning caches for device tree [11fff000-11fff823] ([13bff000]) VMM[main]: Populating RAM of virtual machine VMM[mmio]: Mapping [2000000 - 11ffffff] -> [3c00000 - 13bfffff] VMM[mmio]: Mapping [GICC] -> [f1060000 - f1060fff] VMM[mmio]: Mapping [1e000 - 1e0ff] -> [f1120000 - f11200ff] IO | new iomem region: p=000000fe000000 v=00000000400000 s=400000 (bmb=0x36100) IO | map mem: p=000000fe300000 v=00000000700000 s=1000: done(0) VMM[mmio]: Mapping [200000 - 2000ff] -> [fe300000 - fe3000ff] VMM[]: reschedule(): Initiating cpu startup for 418000 VMM[guest]: Powered up cpu0 [0x1f010] VMM[]: Starting Cpu0 @ 0x3c00000 in 64Bit mode (handler @ 103ed60, stack: 8000fba0, task: 41e000, mpidr: 80000000 (orig: 80000000) VMM[]: 04bab7c8: msr PMUSERENR_EL0 = 00000000 (ignored) VMM[]: ffff800010013d68: msr OSDLR_EL1 = 00000000 (ignored) VMM[]: ffff800010013d6c: msr OSLAR_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee5c: msr DBGBCR0_EL1 = 00000000 (ignored) VMM[]: ffff80001002ef1c: msr DBGBVR0_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee50: msr DBGBCR1_EL1 = 00000000 (ignored) VMM[]: ffff80001002ef10: msr DBGBVR1_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee44: msr DBGBCR2_EL1 = 00000000 (ignored) VMM[]: ffff80001002ef04: msr DBGBVR2_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee38: msr DBGBCR3_EL1 = 00000000 (ignored) VMM[]: ffff80001002eef8: msr DBGBVR3_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee2c: msr DBGBCR4_EL1 = 00000000 (ignored) VMM[]: ffff80001002eeec: msr DBGBVR4_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee20: msr DBGBCR5_EL1 = 00000000 (ignored) VMM[]: ffff80001002eee0: msr DBGBVR5_EL1 = 00000000 (ignored) VMM[]: ffff80001002ecdc: msr DBGWCR0_EL1 = 00000000 (ignored) VMM[]: ffff80001002ed9c: msr DBGWVR0_EL1 = 00000000 (ignored) VMM[]: ffff80001002ecd0: msr DBGWCR1_EL1 = 00000000 (ignored) VMM[]: ffff80001002ed90: msr DBGWVR1_EL1 = 00000000 (ignored) VMM[]: ffff80001002ecc4: msr DBGWCR2_EL1 = 00000000 (ignored) VMM[]: ffff80001002ed84: msr DBGWVR2_EL1 = 00000000 (ignored) VMM[]: ffff80001002ecb8: msr DBGWCR3_EL1 = 00000000 (ignored) VMM[]: ffff80001002ed78: msr DBGWVR3_EL1 = 00000000 (ignored) VQ[0x1cb30]: num=256 d:0x4c14000 a:0x4c15000 u:0x4c16000 VQ[0x1cb78]: num=256 d:0x4c0c000 a:0x4c0d000 u:0x4c0e000 [ 1.400282] cacheinfo: Unable to detect cache hierarchy for CPU 0 [ 1.414509] loop: module loaded [ 1.418690] megasas: 07.714.04.00-rc1 [ 1.425640] libphy: Fixed MDIO Bus: probed [ 1.431368] tun: Universal TUN/TAP device driver, 1.6 [ 1.437279] thunder_xcv, ver 1.0 [ 1.440867] thunder_bgx, ver 1.0 [ 1.444438] nicpf, ver 1.0 [ 1.448109] hclge is initializing [ 1.451734] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version [ 1.459356] hns3: Copyright (c) 2017 Huawei Corporation. [ 1.465047] e1000: Intel(R) PRO/1000 Network Driver [ 1.470243] e1000: Copyright (c) 1999-2006 Intel Corporation. [ 1.476424] e1000e: Intel(R) PRO/1000 Network Driver [ 1.481710] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. [ 1.488029] igb: Intel(R) Gigabit Ethernet Network Driver [ 1.493756] igb: Copyright (c) 2007-2014 Intel Corporation. [ 1.499697] igbvf: Intel(R) Gigabit Virtual Function Network Driver [ 1.506325] igbvf: Copyright (c) 2009 - 2012 Intel Corporation. [ 1.512801] sky2: driver version 1.30 [ 1.517367] VFIO - User Level meta-driver version: 0.3 [ 1.524155] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.531114] ehci-pci: EHCI PCI platform driver [ 1.535919] ehci-platform: EHCI generic platform driver [ 1.541542] ehci-orion: EHCI orion driver [ 1.545902] ehci-exynos: EHCI Exynos driver [ 1.550435] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.556998] ohci-pci: OHCI PCI platform driver [ 1.561801] ohci-platform: OHCI generic platform driver [ 1.567415] ohci-exynos: OHCI Exynos driver [ 1.572213] usbcore: registered new interface driver usb-storage [ 1.580207] i2c /dev entries driver [ 1.587651] sdhci: Secure Digital Host Controller Interface driver [ 1.594246] sdhci: Copyright(c) Pierre Ossman [ 1.599228] Synopsys Designware Multimedia Card Interface Driver [ 1.606125] sdhci-pltfm: SDHCI platform and OF driver helper [ 1.612955] ledtrig-cpu: registered to indicate activity on CPUs [ 1.620526] usbcore: registered new interface driver usbhid [ 1.626435] usbhid: USB HID core driver [ 1.634165] NET: Registered protocol family 17 [ 1.639199] 9pnet: Installing 9P2000 support [ 1.643874] Key type dns_resolver registered [ 1.648725] registered taskstats version 1 [ 1.653117] Loading compiled-in X.509 certificates [ 1.659117] Btrfs loaded, crc32c=crc32c-generic, integrity-checker=on, zoned=no [ 1.667260] ALSA device list: [ 1.670540] No soundcards found. [ 1.674948] VFS: Cannot open root device "mmcblkp3" or unknown-block(0,0): error -6 [ 1.683078] Please append a correct "root=" boot option; here are the available partitions: [ 1.691888] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 1.700521] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0 #2 [ 1.706738] Hardware name: L4 VM (DT) [ 1.710614] Call trace: [ 1.713229] dump_backtrace+0x0/0x1b0 [ 1.717121] show_stack+0x1c/0x70 [ 1.720653] dump_stack+0xd0/0x12c [ 1.724272] panic+0x16c/0x334 [ 1.727531] mount_block_root+0x1bc/0x24c [ 1.731768] mount_root+0x104/0x138 [ 1.735469] prepare_namespace+0x134/0x174 [ 1.739793] kernel_init_freeable+0x260/0x2a4 [ 1.744398] kernel_init+0x18/0x124 [ 1.748108] ret_from_fork+0x10/0x30 [ 1.751908] Kernel Offset: disabled [ 1.755604] CPU features: 0x10000071,00000846 [ 1.760204] Memory Limit: none [ 1.763464] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- ------8<------------------------------------------------------------------------------------------------

2 2

l4re + l4linux on aarch64 - raspi4
by Matthieu Fatrez 12 Sep '21

12 Sep '21

Hello l4-hackers, I tried to use l4re hypervisor on raspberry pi 4. Prebuild image works but not for my needs. In fact, I want to use l4re running on raspberry pi 4 (aarch64) with 1 or more tasks (such hello, ...) and 1 linux 64 bits vm like debian, fedora or opensuse. When I try to compile : - x86_64 (native) : fiasco, l4re, l4linux no problem, - rpi3, 32bit (cross compile) : fiasco, l4re, l4linux no problem - rpi4 64bit (cross compile) : fiasco l4re OK but nothing for l4linux :-( In this last case, obj/l4linux directory is empty. Nothing created. Normal? Do you have some advices for me please? Thank you very much Matthieu.

2 3

Change in l4re_rm_attach behaviour?
by Paul Boddie 28 Aug '21

28 Aug '21

Hello, The long journey of developing components for L4Re continues - a story for another time, perhaps - and I have been testing code that works with the old Subversion-based L4Re distribution on the newer Git-based L4Re distribution. One thing that seems to be different between the old and the new is when a call like the following is performed: l4re_rm_attach(addr, size, L4RE_RM_SEARCH_ADDR, ds, offset, L4_PAGESHIFT); Apart from L4RE_RM_SEARCH_ADDR seemingly being replaced by a differently-named constant, L4RE_RM_F_SEARCH_ADDR, it appears that such a value for the flags is insufficient and that additional rights flags might be required. If I omit such rights flags, I get the L4_ENOENT error value, but this worked before. So, I think I may have misunderstood the behaviour of the function. Or are there now additional constraints imposed by the region manager that prevent any inappropriate accesses from bothering the dataspace? (My dataspace does test the flags on map requests against the rights supported by the dataspace itself.) Another difference that I see between the old and the new is in the flags used for map requests sent to dataspaces. In the old distribution, there were these definitions (in pkg/l4re-core/l4re_c/include/dataspace.h): L4RE_DS_MAP_FLAG_RO = 0, L4RE_DS_MAP_FLAG_RW = 1, It appears that map requests now use the following: L4RE_DS_F_R = L4_FPAGE_RO, L4RE_DS_F_W = L4_FPAGE_W, L4RE_DS_F_X = L4_FPAGE_X, L4RE_DS_F_RW = L4_FPAGE_RW, L4RE_DS_F_RX = L4_FPAGE_RX, L4RE_DS_F_RWX = L4_FPAGE_RWX, I think the actual values involved here are different, but I imagine that since everything should be manipulating values derived from these definitions (as opposed to maintaining separate definitions of the flags), no incompatibility would normally be observed. But the apparent lack of conservatism surprised me slightly. Anyway, if anyone has any insight into why the attach operation behaviour is different, I would very much appreciate it! Paul

2 3

L4Re on Raspi 3
by Yanneck Geiger 20 Jun '21

20 Jun '21

Hello, unfortunately I can't get L4Re running on the Raspberry Pi 3 / 3+ using the provided Guider (https://l4re.org/rpi.html) I did the 64-Bit setup accordingly with the provided U-Boot and the ready-to-use images. U-Boot itself seems to work fine and I can set the IPs ... Unfortunately I don't know the address to load the .elf file so I'm using the following commands: "tftpboot bootstrap_hello_rpi3.elf" and "bootelf". After entering "bootelf" the output on serial spews garbage and after a few seconds the same garbage is "printed" in an interval of around 1 second. Am I doing anything wrong or am I missing something? Kind Regards Daniel

3 4

Resource sharing
by John Galt 04 Apr '21

04 Apr '21

Is it possible to share resources between two VMs running Linux? After defining the io_bus and the io configuration, just one VM is getting access to the resource while the other displays: ERROR: binding irq 34, result is -1 (operation not permitted) "VMM: FATAL: Device creation for virtual device failed". Terminate called after throwing an instance of 'N2L413Runtime_errorE' what: Operation not permitted: cannot bind to IRQ

2 1

Build tutorial for the Zynq Ultrascale+
by Jorge Miguel Perez Utrera 01 Apr '21

01 Apr '21

Hi, I am trying to build the first tutorial, but cross-compiling for the Zynq Ultrascale+. However, when I run "make E=hello qemu" I get the next output: Image size(s) in bytes: bootstrap_hello.elf: 1275456 Start address: 0x1000000 --> Build-Nr: 5 QEMU-cmd: qemu-system-aarch64 -kernel /home/jperezu/build-arm/images/bootstrap.elf -serial stdio -M xlnx-zcu102 -cpu cortex-a53 -m 1024 -display none L4 Bootstrapper Build: #5 Thu Apr 1 23:34:21 CEST 2021, 10.2.0 Scanning up to 2048 MB RAM, starting at offset 32MB Memory size is 2048MB (00000000 - 7fffffff) RAM: 0000000000000000 - 000000007fffffff: 2097152kB Total RAM: 2048MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 1100000 moving module 04 { 10ad000-10d99bf } -> { 1199000-11c59bf } [182720] moving module 03 { 108f000-10aca0f } -> { 117b000-1198a0f } [121360] moving module 02 { 105b000-108e54f } -> { 1147000-117a54f } [210256] moving module 01 { 1055000-105abef } -> { 1141000-1146bef } [23536] moving module 00 { 1014000-1054cef } -> { 1100000-1140cef } [265456] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 3000 Regions of list 'regions' [ 1000, 4afff] { 4a000} Kern fiasco [ 4b000, 4b0ef] { f0} Root mbi_rt [ 100000, 10a46f] { a470} Sigma0 sigma0 [ 140000, 170e43] { 30e44} Root moe [ 171e48, 17eed7] { d090} Root moe [ 1000000, 1012d63] { 12d64} Boot bootstrap [ 10131ef, 10135af] { 3c1} Boot modinfo [ 117b000, 11c59bf] { 4a9c0} Root Module found kernel options (via ELF) at 4000 Sigma0 config ip:00100474 sp:00000000 Roottask config ip:00141694 sp:00000000 Starting kernel fiasco at 000016b0 Hello from Startup::stage2 Number of IRQs available at this GIC: 192 Assertion failed at /home/jperezu/fiasco/src/kern/irq_mgr_multi_chip.cpp:67: mask Does anyone know what could be the problem? I am using CROSS_COMPILE:=aarch64-linux-gnu- to build and ARM64 architecture, ARMv8a CPU variant, Xilinx Zynq Ultrascale+, and CPU Arm Cortex-A53 in the configuration. Thank you for your help. Sincerely, Jorge

2 1

search CPP u-kernel, i knock in the good dors ?
by heitai 21 Mar '21

21 Mar '21

Hi, I search a CPP u-kernel, fiasco seems the best way but i see L4 not writting in CPP... dude, and the first code i was read isn't commented (kernel_console.cpp) may be i thinks my first stuff is comment fiasco... about kernel_console, why kconsole ? not native console writing ? may be i try to write on... i follow learn C++ programming by delanoy in french, may be take some time but kconsole seems thinks me to kde console, may be i missing. take care and best regard, heitai.

2 1

Invitation: Systems Software Innovations Summit 2021
by Martin Decky 17 Mar '21

17 Mar '21

Dear colleagues, I would like to cordially invite you to participate in Huawei Systems Software Innovations Summit 2021 on March 30th and 31st 2021. This is an on-line conference focused on research and practical aspects of operating systems, microkernel-based systems, formal verification and related topics. Notable speakers are Greg Kroah-Hartman (Linux Foundation), Timothy Roscoe (ETH Zurich), Hermann Härtig (TU Dresden), June Andronick (UNSW) and others. There is no fee for participation. Accessing the live on-line stream requires just a simple registration. More information at https://huawei-events.de/ We are looking forward to your participation! Best regards Martin Decky Principal Research Engineer Dresden Research Center Huawei Technologies

1 0

L4Re: region mapper/manager concurrency considerations and resource limits
by Paul Boddie 02 Mar '21

02 Mar '21

Hello, Apologies for introducing two potentially separate topics, but they both seem to present themselves in my most recent endeavour. In short, I am wondering about the following... What considerations need to be given to concurrency with regard to the use of the l4re_rm_attach function and similar functionality? Is access to the region mapper/manager from different threads in the same task advisable, are there thread safety issues, and if so, can these be sensibly worked around? (I have observed what seems to be the same address being provided for two different dataspaces at the same time, which does not appear to happen when I introduce locking around calls to l4re_rm_attach. Are such problems expected or could this be some other problem manifesting itself?) What kind of resource limits apply to L4Re tasks? In my work, I am allocating capabilities for objects acting as dataspaces. Things seem to work fairly well up to a certain point, and then capability allocation seems to fail, and program failure is then not particularly graceful. (I currently observe that creating 160 threads, each with its own IPC gate capability seems to be unproblematic, but more than this will produce errors that manifest themselves either in pthread library code or in my own code where a critical section is supposed to be enforced.) I suppose some contextual remarks might be useful. My previous work involved providing some simple filesystem-related functionality through filesystem servers, where a new server object (exposed via an IPC gate and having its own thread) is created for each open file. Some stress testing in a multiprocessor environment indicated that various concurrency issues were highly likely to be present. (I also probably didn't provide general enough support for flexpages, but since all my "send" flexpages were single machine pages, I don't think this would have caused additional problems or confusion.) Consequently, I migrated the principal mechanisms to my Linux environment and wrote a simulation to explore the concurrency situation, identifying and hopefully remedying various deficiencies (including more general flexpage support). This new endeavour involves bringing this tested functionality back into L4Re, wiring it up with the IPC system, and testing using multithreaded clients. I might also ask about support in L4Re for C++ threading constructs. When developing my simulation, I decided to use the standard C++ support for threading, mutexes, condition variables, and so on, as opposed to using pthread functionality. I imagine that C++ library support for these things just wraps the pthread functionality, but I wonder if there are not other considerations that I might need to be aware of. Sorry if this is in any way vague, but since there isn't really any discussion about system architecture or implementation on this list with respect to these technologies (or really any technologies), I find myself experimenting with the available software to determine techniques and approaches that I hope will be viable. Nevertheless, any constructive remarks or advice would be greatly appreciated. Thanks in advance, Paul

3 11

Boot problems with Fiasco.OC on the NanoPC-T3 Plus
by Andreas Resch 25 Jan '21

25 Jan '21

Hello everyone, as part of a practical course at my university my group has to bring Fiasco.OC and L4re to the NanoPC-T3 Plus which is powered by the S5P6818 from Samsung/Nexell. We’re currently stuck on multiple fronts, and as a sort of last resort I’m asking here for help, I hope you don’t mind. 1. Problem - The RAM We implemented a working uart driver for our board and when using all (seemingly) correct values for the RAM region (as stated in the TRM is located from 0x40000000 to 0xc0000000) our SBC only boots up to the message “Hello from Startup::stage2” and then hangs in the function Kmem_alloc::Kmem_alloc() , we believe because the value of Map_base is with 0xffff000040000000 far too big but haven’t found a way to fix this issue whilst keeping the correct RAM region. Does someone have an idea why setting the incorrect RAM region results in more progress in the boot process (as stated in the following paragraph)? 2. The Timer - or the lack thereof When we were experimenting with the RAM size we found that when setting to to 3GB starting from 0x40000000 we achieve slightly more output. Right up to ARM generic timer, which seems to not work on this particular board, we decided to implement our own timer driver, now we are stuck at Panic: Trace buffer size unaligned which, upon investigation, was an output from the JDB; by disabling the debugger we could again get more output, seen below. The clock doesn’t seem to start counting and I currently have no idea how to implement my own clock driver, I was hoping the generic clock would suffice. Bytes transferred = 1223880 (12acc8 hex) ## Booting kernel from Legacy Image at 40080000 ... Image Name: L4 Image #428 Image Type: AArch64 Linux Kernel Image (uncompressed) Data Size: 1223816 Bytes = 1.2 MiB Load Address: 41000000 Entry Point: 41000000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... L4 Bootstrapper Build: #428 Thu Jan 14 22:44:58 CET 2021, 7.5.0 RAM: 0000000040000000 - 00000000ffff0000: 3145664kB Total RAM: 3071MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 41100000 moving module 02 { 410dd000-4112ac87 } -> { 411cb000-41218c87 } [318600] moving module 01 { 410c4000-410dcea7 } -> { 411b2000-411caea7 } [102056] moving module 00 { 41077000-410c34cf } -> { 41165000-411b14cf } [312528] moving module 04 { 4103f000-41076bbf } -> { 4112d000-41164bbf } [228288] moving module 03 { 41012000-4103ee4f } -> { 41100000-4112ce4f } [183888] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 40003000 Regions of list 'regions' [ 40000000, 400000ef] { f0} Root mbi_rt [ 40001000, 40058fff] { 58000} Kern fiasco [ 400f0000, 40108a5b] { 18a5c} Sigma0 sigma0 [ 40118a60, 4011c2ef] { 3890} Sigma0 sigma0 [ 40130000, 4017d4cf] { 4d4d0} Root moe [ 4018d4d0, 40198d67] { b898} Root moe [ 41000000, 41011193] { 11194} Boot bootstrap [ 41100000, 41164fff] { 65000} Root Module found kernel options (via ELF) at 40004000 Sigma0 config ip:401002bc sp:00000000 Roottask config ip:401413ec sp:00000000 Starting kernel fiasco at 40001818 Hello from Startup::stage2 Number of IRQs available at this GIC: 160 Detecting PSCI ... Detected PSCI v1.1 PSCI: CPU_SUSPEND format extended, supports OS-initiated mode PSCI: TOS: Not present or not required. SERIAL ESC: allocated IRQ 7 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: cffbd484-dirty compiled with gcc 7.5.0 for Samsung S5P6818 [] Build: #212 Thu Jan 14 22:44:36 CET 2021 Calibrating timer loop… If anyone could maybe guide me into the right direction I’d be more than happy! Thank you very much! Best regards Andreas

4 6