l4-hackers

l4-hackers@os.inf.tu-dresden.de

2827 discussions

CfP: Microkernel and Component-based OS Devroom at FOSDEM 2022
by Martin Decky 06 Dec '21

06 Dec '21

Microkernel and Component-based OS Devroom at FOSDEM 2022 CALL FOR PARTICIPATION On-line version of this CfP: http://fosdem.microkernel.info/ The developers and users of several free and open source microkernel-based and component-based operating systems will meet on-line as part of FOSDEM 2022 [1] and will share a developer room. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-based, unikernel-based, component-based operating systems and similar topics. The devroom has been preliminarily scheduled to Saturday February 5th 2022. The devroom will take place during European day hours. Possible topics of the devroom include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * languages, tools and toolchains used * enabling support for hardware (architectures, device drivers) and programming languages * development processes, debugging * maintenance, testing and release engineering * safety, security and robustness * trends and challenges * research and open questions * community and governance * use cases, experiences and status updates * best practices and lessons learned * demos This is a call for your participation. We kindly ask you to submit your proposals no later than on December 28th 2021. Please use the Pentabarf web site [2] to submit your proposals. If you already have a user account in Pentabarf, please do not create a new one. Addtionally, make sure to select the Microkernel and Component-based OS Devroom as the track when submitting your talk and include at least the following information in your proposal: * title of your talk * your full name * short abstract of your talk (one or two paragraphs) * duration of your talk (at least 20 minutes and no longer than 50 minutes) * your short bio * your photo The talks will be pre-recorded in advance in January and streamed automatically during the event. This means that you will need to complete and submit your talk recording by January 15th 2022. However, each speaker should be also present on-line just after the streaming of their talk for a live Q&A. You can specify your prefered time slot of your talk. The communication language of the devroom is English. The official devroom schedule (along with the accepted talks) will be announced on December 31st 2021 on the devroom's mailing list [3] and the speakers will be notified via e-mail. The schedule will also be published on the FOSDEM web site. For any comments, questions and suggestions (e.g. suggestions for a different type of event during the devroom), please do not hesitate to use the devroom's mailing list [3]. About the Devroom Since the first Microkernel OS Devroom at FOSDEM 2012 [4], this devroom has been a part of each following FOSDEM (with slight variations of the name). The focus gradually widened to include component-based, unikernel-based and other operating systems. By now, it has become a somewhat institutionalized tradition for the open source operating systems community and it is one of the few places where microkernel enthusiasts and people with different views on how operating systems should work meet regularly. To this date, over a dozen projects have participated in one way or another. Many of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. Extraordinary Circumstances in 2022 (Again) Due to the extraordinary mode of organization of FOSDEM 2022 (being an on-line event again), the devroom talks will be required to be pre-recorded in January and streamed during the event (with a live Q&A). The talk videos will be published under Creative Commons license by FOSDEM. By submitting a recorded talk, the speaker agrees to have it made available publicly indefinitively. For organizational purposes, we also need contact information of the speakers of accepted talks. Please check the official CfP page [5] of the devroom regularly. We will keep updating it as technical guidelines will be set by the FOSDEM organizers. Microkernel Dinner Sadly, it will not be possible to arrange our traditional microkernel dinner and other in-person social gatherings in Brussels this time again. However, we plan a closing event of the devroom as a loose approximation of the microkernel dinner. The details will be announced later. We encourage the on-line participats to bring their own food and beverages. About FOSDEM FOSDEM [6] is a two-day event organized by volunteers to promote the widespread use of free and open source software. FOSDEM is widely recognized as one of the best such conferences worldwide. FOSDEM covers a wide spectrum of free and open source software and hardware projects and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) where teams can meet and showcase their projects. Devrooms are a place for teams to discuss, hack and publicly present latest directions, lightning talks, news and proposals. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. In recent years, FOSDEM has been hosting more than 5000 developers annually at the ULB Solbosch campus. Due to the circumstances, FOSDEM 2022 will be organized as an on-line event. The participation in FOSDEM is totally free, although the organizers gratefully accept donations and sponsorship. No registration is necessary, but attendees are expected to follow the FOSDEM's code of conduct [7]. Important Dates Recap * 2021-12-28: Deadline for talk proposal submission * 2021-12-31: Schedule published and speakers notified of acceptance * 2022-01-15: Deadline for talk pre-recoding submission * 2022-02-05: Devroom taking place on-line Contact In case of any comments, questions and suggestions, please do not hesitate to contact the devroom organizers via the devroom's mailing list [3]. The primary organizers of the devroom in 2022 are: * Sebastian Sumpf * Martin Decky Links [1] https://fosdem.org/2022/ [2] https://penta.fosdem.org/submission/FOSDEM22/ [3] https://lists.fosdem.org/listinfo/microkernel-devroom [4] https://archive.fosdem.org/2012/schedule/track/microkernel_os_devroom.html [5] http://fosdem.microkernel.info/ [6] https://fosdem.org/ [7] https://fosdem.org/2022/practical/conduct/

1 0

Basic support for HiKey960 & SMP question
by Martin Decky 05 Oct '21

05 Oct '21

Dear L4 hackers, I have implemented a basic support for the HiKey960 board (based on the Kirin 960 SoC) [1] in Fiasco.OC and L4Re. If you are interested, please feel free to examine the code at GitHub [2]. I would be more than happy for a code review and suggestions towards potential upstream merging. The code is based on the latest L4Re base 21.07.0 snapshot. I have wanted to rebase the implementation on the latest revisions of the respective GitHub repositories, but unfortunately the current upstream Fiasco does not work for me properly even in QEMU. The implementation is very basic (fixed physical memory layout, UART support only, etc.), but seems to be working fine on the default examples. Unfortunately, I am struggling for some time with making the additional CPU cores work. I would greatly appreciate your assistance in this matter. In a nutshell, the additional 3 little cores (A53) are woken up correctly using the PSCI call (I am not tackling the 4 big A73 cores yet), but the Fiasco code livelocks in the loop around the STXR instruction in src/kern/arm/64/tramp-mp.S [3]. The STXR instruction always reports that the exclusive access to the _tramp_mp_spinlock failed despite no other accesses to the spinlock happened (confirmed using a JTAG debugger). I have checked all the usual culprits like proper virtual memory mapping attributes. I don't see any significant difference between the initialization code of Fiasco and the initialization code of other kernels that support HiKey960. I am also aware of the recent Adam's fix to the _tramp_mp_spinlock code [4], but not even that fixes the livelock issue on HiKey 960. Does anyone have any idea what might be root cause of the livelock here? Thanks in advance for any input. [1] https://www.96boards.org/product/hikey960/ [2] https://github.com/martin-decky/L4Re-HiKey960 [3] https://github.com/martin-decky/L4Re-HiKey960/blob/master/src/fiasco/src/ker n/arm/64/tramp-mp.S#L247 [4] https://github.com/kernkonzept/fiasco/commit/6bc2f7132982bc1e159abb716eb9026 71d381e9e Best regards Martin Decky

4 7

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 21 Jun '21

21 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 02 Apr '21

02 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 22 Mar '21

22 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers