- l4-hackers - example.com Site

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

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

Fiasco.OC won't boot on Aaeon FWS2360 ...
by Andreas Steinmetzler 19 Dec '20

19 Dec '20

Hi, in some experiments I'm trying to run Fiasco/L4re on a Aaeon FWS2360 (https://www.aaeon.com/en/p/desktop-network-appliance-fws-2360) with an Intel Atom C3558. Unfortunately Fiasco gets stuck on boot when trying to start the different cores of the processor (I'm using the latest published l4re-snapshot-20.10.0). For this test I'm using the "hello world" ISO build with this command make E=hello grub2iso MODULE_SEARCH_PATH="${PWD}/../build-fiasco-amd64" The ISO image boots fine on another amd64 system. After adding some printf()'s to the file kernel_thread-ia32.cpp it looks to me that things get stuck with this call: // Send IPI-Sequency to startup the APs Apic::mp_startup(Cpu::boot_cpu(), Apic::APIC_IPI_OTHERS, tramp_page); as it does not return anymore ... any hint how to debug this or drill down to get more information and the AtomC3558 system to boot? Thanks Andreas L4 Bootstrapper Build: #2 Mon Dec 14 12:09:54 PST 2020, x86-64, 7.5.0 RAM: 0000000000000000 - 00000000000997ff: 614kB RAM: 0000000000100000 - 000000003e2dffff: 1017728kB RAM: 000000003e300000 - 0000000078762fff: 954764kB RAM: 0000000078773000 - 000000007de44fff: 88904kB RAM: 000000007f34b000 - 000000007f7fffff: 4820kB RAM: 0000000100000000 - 000000087fffffff: 31457280kB Total RAM: 32738MB Scanning fiasco -serial_esc Scanning sigma0 Scanning moe --init=rom/hello need 272 bytes to copy MBI reserved 272 bytes at 0x2000 Moving up to 5 modules behind 1100000 moving module 00 { 1021000-1246617 } -> { 119b000-13c0617 } [2250264] moving module 04 { 170000-19b95f } -> { 116f000-119a95f } [178528] moving module 03 { 152000-16f72f } -> { 1151000-116e72f } [120624] moving module 02 { 10e000-15175f } -> { 110d000-115075f } [276320] moving module 01 { 101000-10d48f } -> { 1100000-110c48f } [50320] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 400000 Regions of list 'regions' [ 0, fff] { 1000} Arch BIOS [ 1000, 1fff] { 1000} Kern fiasco [ 2000, 210f] { 110} Root mbi_rt [ 99800, 9ffff] { 6800} Arch BIOS [ e0000, fffff] { 20000} Arch BIOS [ 100000, 11247f] { 12480} Sigma0 sigma0 [ 140000, 18007f] { 40080} Root moe [ 182038, 1940e7] { 120b0} Root moe [ 2d0400, 2e1257] { 10e58} Boot bootstrap [ 300000, 34afff] { 4b000} Kern fiasco [ 400000, 62efff] { 22f000} Kern fiasco [ 1019000, 101efff] { 6000} Boot bootstrap-ptab64 [ 1151000, 119afff] { 4a000} Root Module [ 3e2e0000, 3e2fffff] { 20000} Arch BIOS [ 78763000, 78772fff] { 10000} Arch BIOS [ 7de45000, 7df1cfff] { d8000} Arch BIOS [ 7df1d000, 7df99fff] { 7d000} Arch BIOS [ 7df9a000, 7e3aafff] { 411000} Arch BIOS [ 7e3ab000, 7f34afff] { fa0000} Arch BIOS [ 7f800000, 7fffffff] { 800000} Arch BIOS [ e0000000, efffffff] { 10000000} Arch BIOS [ fd000000, fe7fffff] { 1800000} Arch BIOS [ ff000000, ffffffff] { 1000000} Arch BIOS found kernel options (via ELF) at 401000 Sigma0 config ip:00000000001004a0 sp:0000000000000000 Roottask config ip:00000000001419ed sp:0000000000000000 Starting kernel fiasco at 0000000000300910 Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on amd64 Rev: unknown compiled with gcc 7.5.0 for x86-64 [] Build: #7 Mon Dec 14 11:40:53 PST 2020 Performance-critical config option(s) detected: CONFIG_NDEBUG is off Superpages: yes Kmem:: TSS mem at 8053f9000 (4096Bytes) VMX: enabled VMX: EPT supported VMX: initialized ACPI: RSDP[0xf05b0] r02 OEM:ALASKA FPU0: SSE ACPI: FACS phys=7e3a9080 virt=0x203a9080 ACPI: HW sig=cd SERIAL ESC: allocated IRQ 4 for serial uart VMX: init page sizes SERIAL ESC: allocated IRQ 4 for serial uart Not using serial hack in slow timer handler. CPU[0]: GenuineIntel (6:5F:1:0)[000506f1] Model: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz at 2199MHz Freeing init code/data: 20480 bytes (5 pages) MP: detecting APs... After tramp_page

2 2