- l4-hackers - example.com Site

Kernel allocated memory not visible in L4Re virtual device despite correct physical RAM mapping
by stephen.yang 15 Apr '26

15 Apr '26

Hi l4-hackers, I am trying to pass a kernel-allocated memory buffer to a virtual device, but I am running into an issue. I would appreciate any help or suggestions. 1.Kernel side(driver) In my platform driver, I allocate memory using devm_kzalloc, write a string into it, and pass its physical address to the device via an MMIO register: …… void* buf = devm_kzalloc(&pdev->dev, 0x200, GFP_KERNEL); if (!buf) return -ENOMEM; phys_addr_t pa = virt_to_phys(buf); char *str = "hi stephen"; memcpy(buf, str, strlen(str) + 1); wmb(); writeq((u64)pa, hb->base + 0x00); …… My understanding is: allocate kernel memory → write data → pass physical address to the device. 2. Memory layout I observed that the allocated physical address falls within the RAM regions configured via bootargs : 0x66200000 - 0x6fffffff So my assumption was that if the virtual device maps this physical memory region, it should be able to access the data written by the kernel. 3. Virtual device side (L4Re) On the virtual device side, I map the physical memory using L4Re RM attach: void write(unsigned reg, char /*size*/, l4_uint64_t value, unsigned) { if (reg == 0x00) { addr = value; auto d = L4Re::Env::env()->get_cap<L4Re::Dataspace>("lram"); l4_addr_t vaddr; l4_addr_t base = 0x66200000; l4_addr_t size = 0x09E00000; int r = L4Re::Env::env()->rm()->attach( &vaddr, size, L4Re::Rm::F::Search_addr | L4Re::Rm::F::RW | L4Re::Rm::F::Cache_uncached, L4::Ipc::make_cap_rw(d), 0, L4_PAGESHIFT); if (r) { printf("can't attach hb memory\n"); return; } char *dst = reinterpret_cast<char *>(vaddr + (addr - base)); for (int i = 0; i < 20; i++) { printf("%02x ", (unsigned char)dst[i]); } printf("\n"); printf("get msg for guest: %s\n", dst); } } 4.Problem However, I cannot read the string written by the kernel. The memory content I get appears to be uninitialized or unrelated data. 5.Question I can confirm that the lram dataspace capability does correctly correspond to the physical memory region 0x66200000 - 0x6fffffff, and this region is valid and usable RAM on the system. I am unsure where the issue lies: (1) Is this approach (kernel allocation → pass physical address → direct mapping in virtual device) actually valid? (2) Could this be a cache coherence / DMA issue? (3) Or is there something incorrect in my L4Re RM attach usage? Any insights would be greatly appreciated.

2 1

Mounting the Sd card on the L4re for Imx 95.
by Marka Sriharsha 08 Feb '26

08 Feb '26

The L4Re version I am using is r-2025-W48. Initially, I attempted to boot using the initramfs-based method. In this approach, I converted the uImage into a raw bin image, because loading the uImage directly resulted in a Bad kernel image error, likely due to the default uImage header handling. After flashing the converted binary to the SD card, the system booted but consistently got stuck during early boot. Even when different load addresses are specified in U-Boot, the kernel is always relocated to a fixed address (0x90080000). This address overlaps with a reserved memory region (e.g., vpu_boot@a0000000), leading to a region overlap error and reboot. I'm attracting the log (Initramfs.txt). After this, I switched to the SD card hardware passthrough method. Following the i.MX documentation, I prepared the SD card as follows: Partition 1: FAT partition containing bootstrap.uimage and the i.MX95 device tree Partition 2: Root filesystem As suggested, I updated the configuration (.cfg) file by following the tutorial, and this resolved the console misconfiguration issue. The system now boots correctly, and I am able to see the console output. For reference, I am attaching the boot logs(Boot_partition_2.txt) Although the system boots successfully, the SD card root partition is not being detected or mounted. While following the documented steps to enable SD card access, the boot process ends with a “no device found” error for the SD card. After further debugging, I noticed that for i.MX95, there is nohw_devices.iofile available in the following repository: [https://github.com/kernkonzept/io/tree/master/io/configs] Because of this, it is unclear how the SD/MMC hardware should be described for i.MX95, and the block device does not appear during boot. For reference, I am attaching the boot logs(Boot_partition_3.txt) Is there an official hw_devices.io configuration available for i.MX95? or without the hw_device.io also we can mount the sd card? Any guidance or example configuration would be very helpful for mounting the rootfs.

2 1

Beyond the Bricks: How Google's Block Breaker Doodle Reminds Us of the Joy of Play
by blockbreakerapk10174＠gmail.com 06 Feb '26

06 Feb '26

In the relentless digital stream of our daily lives—a torrent of emails, notifications, and curated content—a moment of pure, unadulterated play can feel like a radical act. It was within this context that, on a seemingly ordinary day, millions of people worldwide were greeted by a delightful surprise on Google’s homepage: the Google Block Breaker Doodle. This wasn’t just a static logo; it was a fully playable, wonderfully crafted version of the classic arcade game, Breakout. With a click, the world’s most ubiquitous search portal transformed into a minimalist arcade, inviting users to smash a wall of colorful <a href="https://blockbreaker.ws/">google block breaker doodle</a> bricks with a bouncing pixel. The phenomenon was more than a nostalgic trip; it was a masterclass in design philosophy, a commentary on workplace culture, and a potent reminder of a fundamental human need. The genius of the Google Block Breaker Doodle lay in its elegant simplicity and its deep-rooted heritage. The original Breakout, released by Atari in 1976, is itself a piece of tech legend. It was a direct descendant of Pong, emphasizing solitary focus and rhythmic precision. More intriguingly, its original development involved a young Steve Jobs and Steve Wozniak, who were tasked with creating its circuit board. For Google to choose this game was a wink to its own Silicon Valley lineage, connecting the dots from the garage-built ethos of early computing to the sleek, global platform of today. The Doodle didn’t just reference a game; it honored a foundational moment in digital interactivity. But the impact went far beyond history. The user experience was perfectly calibrated. The mechanics were instantly understandable: move the paddle, bounce the ball, break the blocks. There were no tutorials, no loot boxes, no complex narratives. The objective was clear, the feedback immediate (the satisfying disappearance of a brick), and the failure state gentle—a chance to try again instantly. This created a state of "flow," that psychological condition of complete immersion and focused enjoyment. In a world of endless scrolling and multitasking, the Google Block Breaker Doodle offered a rare commodity: a single, simple task that commanded full attention. It was a digital mindfulness exercise disguised as a game. The timing and placement of the Doodle were equally significant. By situating this portal to play on the default homepage for countless browsers, Google shattered the traditional boundary between "work" and "play." For a brief moment, the tool we use for research, communication, and productivity became a site of leisure. This wasn’t an app you had to seek out; it was presented, almost insistently, as an alternative path. It encouraged what modern productivity gurus might call a "micro-break"—a short, intentional pause to reset the brain. The message was subtle but powerful: creativity and efficiency are not antithetical to play; they are often fueled by it. The Google Block Breaker Doodle became a sanctioned, global five-minute recess, challenging the grim grind of hustle culture. Furthermore, the Doodle served as a brilliant, unspoken showcase of web technology. This was no mere Java applet from the early 2000s. It was a smooth, responsive, and visually pleasing experience built with modern web standards, demonstrating what a browser could do without any plugins or downloads. It was a testament to the sophistication of accessible web design, proving that complex interactivity could be delivered instantly and seamlessly to anyone with an internet connection. In this way, the playful facade was also a technical flex, a demonstration of Google’s core competency in making the web a more dynamic canvas. On a societal level, the Doodle created a shared cultural moment. Social media lit up with high scores, strategies, and good-natured commiseration over near-misses. Colleagues compared scores by the watercooler. It democratized a specific joy, creating a common reference point across generations. Older users relived childhood memories in arcades or on early home consoles, while younger ones discovered a genre stripped bare of modern gaming’s complexities. The Google Block Breaker Doodle acted as a universal language, speaking through the simple verbs of aim, bounce, and break. Ultimately, the lasting lesson of the Google Block Breaker Doodle is about the enduring human need for purposeless purpose. We are wired to derive satisfaction from mastering simple systems, from seeing a clear cause and effect, and from engaging in activities where the only goal is the activity itself. In our increasingly optimized and outcome-driven lives, we often engineer this joy out of existence. The Doodle was a gentle intervention, a reminder that play is not frivolous. It is essential for cognitive maintenance, sparking joy, relieving stress, and fostering a creative mindset. Google, a company built on algorithms and data, used its most prized real estate to advocate for something beautifully analog in spirit: the click of a mouse, the bounce of a ball, the shattering of a digital wall. The Google Block Breaker Doodle was more than a clever homage; it was a manifesto in interactive form. It argued that within the cold architecture of code and connectivity, there must always be room for a paddle, a ball, and a wall of bricks waiting to be broken. It reminded us that sometimes, the most productive thing we can do is to simply play.

1 0

VMs on L4Re
by Quang 16 Jan '26

16 Jan '26

Dear L4Re team, I'm following your guidance on the steps to get the RPi 4B running with L4Re (https://l4re.org/bsp/rpi.html) I can set up and run very well with your steps. However, I think an image, especially l4re_vm-multi_rpi4.elf, is only for 3 VMs. Could you help me figure out how I can increase the number of VMs, and each VM will run on a different OS, such as Ubuntu, Red Hat, or Kali Linux? Thank you for your support, and have a nice day. Best regards, Quang

2 2

custom virtio
by Baruch Burstein 26 Dec '25

26 Dec '25

Hi all, I am looking into implementing a custom backend for a virtio console (I hope I am using the right terminology. The frontend will be in a VM managed by uvmm). I found 2 seemingly unrelated parts of the code named virtio-console, one under uvmm/server/src/virtio_console.[cc|h] and one under l4virtio/include/server/virtio-console. I am wondering why there are 2, what the difference is and when to use each one? There generally seem to be multiple things named virtio* in uvmm/server/src/, uvmm/server/src/device/, as well as separate repos like the aforementioned l4virtio or virtio-net. Thank you in advance for helping clear this up for me

2 1

Multiple targets in one package
by Baruch Burstein 03 Dec '25

03 Dec '25

Hi. I am trying to build multiple apps in one package. I tried the following but am getting linker errors (of all things!) ``` PKGDIR ?= ../.. L4DIR ?= $(PKGDIR)/../.. TARGET = app1 SRC_CC = app1.cc common.cc REQUIRES_LIBS = libio cxx_libc_io cxx_io libstdc++ include $(L4DIR)/mk/prog.mk TARGET = app2 SRC_CC = app2.cc common.cc REQUIRES_LIBS = libio cxx_libc_io cxx_io libstdc++ include $(L4DIR)/mk/prog.mk ``` What is the right way to do this?

2 1

[FOSDEM'26] Call for Participation: Microkernel and Component-Based OS Devroom
by Sebastian Sumpf 04 Nov '25

04 Nov '25

Hi there, here the CfP for FOSDEM'26: We are happy to announce the CfP for the "Microkernel and Component-Based OS" devroom at the upcoming FOSDEM 2026. Developers and users of various free and open-source microkernel-based and component-based operating systems will meet again at FOSDEM during the weekend of January 31st and February 1st 2026 and will share a developer room. The Microkernel and Component-Based OS devroom is currently looking for your participation in the form of proposals for talks, demos and other related activities. Possible topics for 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, devices 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 * Live demos Important Dates The deadline for submitting proposals is December 1, 2025 (23:55 CET). Please use the FOSDEM website at https://fosdem.org/submit, select the track "Microkernel and Component-Based OS" and include at least the following information: * Title of your proposal * Short abstract (one or two paragraphs) * Duration (20 - 30 minutes, including demos and Q&A) * Your full name * Your short bio The devroom schedule (with accepted talks) will be announced on the devroom website at https://fosdem.org/2026/schedule/track/microkernel by December 15, 2025. The schedule will also be posted to the devroom mailing list and the speakers will be notified via email. Like previous years, the devroom will take place as an in-person event at the ULB Campus Solbosch in Brussels, Belgium during the second half of February 1, 2026 (Sunday). Due to the high number of submissions that FOSDEM received again this year, our devroom has only been allocated half a day. Therefore, the final decision on the duration of the talks will be made by the devroom organizers based on the number of accepted proposals. Given these restrictions, eight to nine half hour slots with a speaking time of 20 to 25 minutes and 5 to 10 minutes of Q&A form the upper limit. Requirements The communication language of the devroom is English. All content must relate to free and open-source software. By participating in the event, you agree to the publication of your talk recordings, slides and other content provided under the same CC-BY license as all other FOSDEM content. All participants are expected to adhere to the Code of Conduct: https://fosdem.org/2026/practical/conduct/ Contact For the 2026 edition, the organizers of the devroom are * Sebastian Sumpf (sebastian.sumpf [at] genode-labs.com) * Josef Söntgen (josef.soentgen [at] genode-labs.com) For any comments, questions and suggestions, please do not hesitate to contact us directly or via microkernel-devroom-manager at fosdem.org. Announcements and inquiries are additionally available through the devroom mailing list https://lists.fosdem.org/listinfo/microkernel-devroom About the Devroom Since the first Microkernel OS Devroom at FOSDEM 2012, this devroom has been a part of each subsequent FOSDEM (with slight variations of the name). The focus gradually widened to include component-based and other operating systems. It has now become somewhat of a tradition for the open-source operating systems community, a kind of "extended family meeting" and it is one of the very few places where microkernel and operating-system enthusiasts meet regularly. To date, over two 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. As in the past, the devroom will offer the stage both to established community members and to newcomers. Our goal is to select talks in an inclusive manner and to create a balanced and unbiased schedule, while keeping the quality of the devroom as high as in previous years. About FOSDEM FOSDEM is a two-day conference organized by volunteers to promote the widespread use of free and open-source software. FOSDEM is widely recognized as one of the largest and best such events 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 new ideas, latest results, 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 in Brussels, Belgium. The participation in FOSDEM is totally free and requires no registration, although the organizers gratefully accept donations and sponsorship. Devroom Dinner Over the years, it has become a tradition that devroom speakers and enthusiasts meet for dinner somewhere in Brussels after the event to continue discussions, socialize and meet old and new friends. We plan to follow that tradition in some form as well in 2026 and will inform you about the exact arrangements later. Hope to see all of you in Brussels! Regards, Sebastian -- Sebastian Sumpf Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

Sculpt 25.10 with Fiasco.OC kernel
by Alexander Boettcher 03 Nov '25

03 Nov '25

Hello, last week Genode released a new version of its open source OS - Sculpt OS 25.10 [0]. I took the opportunity to craft a PC image that also contains an (unofficial and experimental) Sculpt variant based upon a Fiasco.OC kernel [1] version. The variant reflects to large degree the state I presented live during the Systems Meetup [2] gathering at the TU Dresden in January 2025. In case you are interested, feel free to check out [1]. Cheers, Alex. [0] https://genode.org/download/sculpt [1] https://genodians.org/alex-ab/2025-11-02-sculpt-multi-kernel [2] https://ukvly.org -- Alexander Boettcher Genode Labs https://www.genodians.org - https://www.genode.org

1 0

Assertion ‘state() & Thread_vcpu_user' in kernel vgic interrupt processing
by yy18513676366 14 Oct '25

14 Oct '25

Hi l4-hackers, When running a virtual machine, I encounter an assertion failure after the VM has been up for some time. The kernel crashes in src/kern/arm/thread-arm-hyp.cpp, specifically in the function vcpu_vgic_upcall(unsigned virq): vcpu_vgic_upcall(unsigned virq) { ...... assert(state() & Thread_vcpu_user); ...... } Based on source code inspection and preliminary debugging, the problem seems to be related to the management of the Thread_vcpu_user state. （1）Under normal circumstances, the vcpu_resume path (transitioning from the kernel back to the guest OS) updates the vCPU state to include Thread_vcpu_user. However, if an interrupt is delivered during this transition while the receiving side is not yet ready, the vCPU frequently return to the kernel (via vcpu_return_to_kernel) and subsequently process the interrupt through guest_irq in vcpu_entries. In this situation, the expected update of Thread_vcpu_user may not yet have taken place, which seems result in the assert being triggered when a VGIC interrupt is involved. （2）A similar condition seems to occur in the vcpu_async_ipc path. At the end of IPC handling, this function explicitly clears the Thread_vcpu_user flag. If a VGIC interrupt is delivered during this phase, the absence of the expected Thread_vcpu_user state seems to lead to the same assertion failure. I would like to confirm if the two points above are correct, and what steps I should take next to further debug this issue. In addition, I have some assumptions I would like to confirm: First, for IPC between non-vcpu threads, the L4 microkernel handles message delivery and scheduling (wake/schedule) directly, without requiring any forwarding through uvmm. Similarly, interrupts bound via the interrupt controller (ICU) to a non-vcpu thread or handler are also managed by the kernel and scheduler, and therefore do not necessarily involve uvmm. Second, passthrough interrupts, when not delivered in direct-injection mode, are routed to uvmm for handling if they are bound to a vCPU. Likewise, services provided by uvmm (such as virq) are also bound to a vCPU and therefore require forwarding through uvmm. There seems to have been a similar question in the past, but it does not seem to have been resolved. Re: Assertion failure error in kernel vgic interrupt processing - l4-hackers - OS Site I wonder if my questions are related to that post, and if any solutions exist. Thanks!

2 7

Questions regarding L4::Platform_Control
by David Q 13 Oct '25

13 Oct '25

Hello L4 hackers, I would like to thank the community for helping me learn; I am back with more questions. This time it is about L4::Platform_Control 1. It seems IO and UVMM both have this L4::Platform_Control capability, is it correct? 2. I can't seem to create a usable L4::Platform_Control capability in a userland application using the factory from env. Does this mean there is one such platform control capability only? 3. It seems there is a system_suspend() function, and X86 is particularly supported. Does it work right now for ARM? 4. Once system_suspend() is called in an ARM environment, does the kernel communicate with PSCI, which then gets intercepted by Arm trusted firmware? 5. Also, before suspending the entire system, it would seem a good idea to quiesce all threads (except the kernel I assume) and save the CPU/Thread states/contexts. Is there an API that could help with quiescing threads and saving relevant states? I only see the debugger being able to quiesce all threads, but I can't seem to find an API that can save and reload the saved states once we want to exit suspend. These are a lot of question, and I thank anyone who reads them.

1 0

L4 Thread, pthread, comprehension question
by xudino＠gmail.com 23 Sep '25

23 Sep '25

Hello L4 hackers, I hope you are all doing well today. I am hoping to discuss the topic of threads to better my understanding of it, as it seems to be a major building block in L4Re. I have the following questions (using the c++ based libraries.): 1. Is Pthread the official way to create threads in an L4Re application? 2. I have made a L4 thread (to understand how threads work in L4) without the help of pthreads by setting up the Attr, which involved in setting the exception handlers(using rm()), pager (using rm()), instruction pointers, stack pointers, binding, ex_reg() and finally running. All seems well until I try printing a message. It seems seems I am unable to use the printf() function in the instruction pointer function of said thread. The error I get is : ttest | l4re_itas[rm]: unhandled read page fault at 0x141 pc=0x100f8a0 ttest | l4re_itas: rom/thread_test: Unhandled exception: PC=0x100f8a0 PFA=0x140 LdrFlgs=0x0 However, if I use printf in a pthread, none of these errors pop up. 2a. Am I using the wrong exception handler and pager (I got both from rm)? 2b. Also, the "l4_vcon_send(L4_BASE_LOG_CAP,..,...) function seems to work fine in either case, shouldn't printf() eventually call this function as after a series of indirections? 2c. What exc_handler and pager do pthreads use? Why are they able to handle the pager faults and exceptions from printf? Can I appropriate them for the L4 threads I started? 3. It seems the Virtual Machines (VMs) that are on the hypervisor are also closely related with threads. I assume these are Vcpu threads and not pthreads. 3a. Am I correct in this assumption? 3b. How are the exception handlers and pagers set up for these Vcpus? Thank you so much for your time, David

3 3

Re: L4 Thread, pthread, comprehension question
by Marcus Haehnel 23 Sep '25

23 Sep '25

Hi David, On 2025-09-22 05:37, xudino(a)gmail.com wrote: > Hello L4 hackers, I hope you are all doing well today. > > I am hoping to discuss the topic of threads to better my understanding > of it, as it seems to be a major building block in L4Re. I have the > following questions (using the c++ based libraries.): > > 1. Is Pthread the official way to create threads in an L4Re > application? That is at least the high level primitive that you should use if you have no good reason to use the low level L4 primitives and want to use any of the POSIX / libc functionality inside your thread. > > 2. I have made a L4 thread (to understand how threads work in L4) > without the help of pthreads by setting up the Attr, which involved in > setting the exception handlers(using rm()), pager (using rm()), > instruction pointers, stack pointers, binding, ex_reg() and finally > running. All seems well until I try printing a message. > It seems seems I am unable to use the printf() function in the > instruction pointer function of said thread. The error I get is : > ttest | l4re_itas[rm]: unhandled read page fault at 0x141 > pc=0x100f8a0 > ttest | l4re_itas: rom/thread_test: Unhandled exception: > PC=0x100f8a0 PFA=0x140 LdrFlgs=0x0 > However, if I use printf in a pthread, none of these errors pop up. > 2a. Am I using the wrong exception handler and pager (I got both > from rm)? > 2b. Also, the "l4_vcon_send(L4_BASE_LOG_CAP,..,...) function seems > to work fine in either case, shouldn't printf() eventually call this > function as > after a series of indirections? > 2c. What exc_handler and pager do pthreads use? Why are they able > to handle the pager faults and exceptions from printf? Can I > appropriate > them for the L4 threads I started? What you are seeing is a side-effect of libpthread being quite tightly integrated with the libc. While it is true that printf will call l4_vcon_send somewhen down the line it will use some (potentially thread-local) internal buffers to print its output. While you can mix libpthread threads with native L4 threads you must take care to call no function from the libc that would make any use of TLS storage, unless you set this up yourself. If you want to write normal applications std::thread and pthread threads are the way to go. > > 3. It seems the Virtual Machines (VMs) that are on the hypervisor are > also closely related with threads. I assume these are Vcpu threads and > not pthreads. > 3a. Am I correct in this assumption? > 3b. How are the exception handlers and pagers set up for these > Vcpus? Yes, a vCPU is in the end only a thread with some extended state. A thread in vcpu mode provides an additional exception execution context. When a trap from avcpu occurs the kernel will switch the vCPU to the exception entry point. See entry_ip and entry_sp here https://l4re.org/doc/structl4__vcpu__state__t.html#a1f45174954aa47bb2f21b7b… These must be set as part of the vcpu state before starting the vcpu. The exception handler must take care of handling page-faults generated by threads user code. I hope this helps :) Best regards, - Marcus > > Thank you so much for your time, > David > _______________________________________________ > l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de > To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de

2 1

Help: interactive REPL I/O for user program on L4Re/Fiasco.OC (amd64-plain) — Vcon/cons nearly working; canonical approach?
by Robert A. James 07 Sep '25

07 Sep '25

Hello l4-hackers, My name is Robert (Bob) A. James I'm VERY new to the L4Re world. This is also my first foray into systems programming having come from the Medical Device and Enterprise areas during my career. I am now retired and developing a full Operating System based on L4Re/Fiasco.OC. I’m looking for guidance on the /canonical/ way to wire an interactive text console (stdin/stdout) for a user program under L4Re/Fiasco.OC on amd64-plain. Context * I have a small, headless FORTH VM (“StarForth”) running under L4Re/Fiasco.OC; its self-tests pass. What’s missing is an *interactive REPL*. * Target outcomes: a) Run via |make qemu E=starforth O=build-x86_64| b) Build GRUB2 ISO via |make grub2iso E=starforth O=build-x86_64| c) ISO runs in QEMU and VirtualBox d) Same ISO boots on commodity x86_64 hardware What I’ve tried (and where I’m stuck) 1. *Vcon + cons* (almost there) * My mental model: Vcon as a frontend; |cons| providing the console service; StarForth as the “backend” client/subscriber. * Behavior I see: • The “terminal” prints what the *logger* prints rather than the process’s normal *stdout*. • Output sometimes *flushes only on newline*; interactive prompts without |\n| don’t appear reliably. * Aside from those two issues, this was close to a working REPL. * *Questions:* Is |cons| effectively write-only (log)? If so, what’s the supported input-capable console frontend to bind both stdin and stdout for a user process? Is there a minimal example showing correct capability wiring so user stdout/stderr don’t get mixed with the system log? 2. *GOOS/Framebuffer route* * I attempted a tiny terminal server that maps the GOOS framebuffer and renders an 8×16 CP437 font. I did not get this path working end-to-end, so I’m fine dropping it if there’s a simpler, recommended console approach. What would help * The *recommended minimal pattern* (modules/services + boot script) to give a user task a real interactive stdin/stdout: o works with |make qemu …| and |make grub2iso …| o also works on typical PCs without a full graphics stack. * A *small reference* that: (1) prints text, and (2) reads keystrokes from the user, with a snippet of |modules.list| and the Lua loader snippet. Environment / details * L4Re/Fiasco.OC on amd64-plain, built with the L4Re toolchain. * Intended entry points: |make qemu E=starforth O=build-x86_64|, |make grub2iso E=starforth O=build-x86_64|. One of my simple boot variants (for reference): |modules.list| (simplified) entry starforth kernel fiasco -serial_esc roottask moe rom/quark.cfg module l4re module ned module cons module quark.cfg module starforth |quark.cfg| --> I think this is about what I had. -- rom/quark.cfg local L4 =require("L4") local ld =L4.default_loader -- Start cons; feed it to the real serial logger (fe =L4.Env.log) local cons_ctl =ld:new_channel() ld:start({ caps = { cons = cons_ctl:svr(), -- server gate for cons' factory fe = L4.Env.log, -- cons frontend goes to serial/log }, }, "rom/cons -m l4re -f fe -a -t -c StarForth") -- ← added -c StarForth -- Ask cons to create a Vcon client for StarForth and pass it in as 'tty' -- (Capabilities are first-class in Ned; calling 'create' on caps is supported.) local tty =cons_ctl:create(L4.Proto.Log, "StarForth", "show", "key=1", "bufsz=65536") -- Start StarForth with that Vcon as its TTY ld:start({ caps = { tty = tty, -- the Vcon client for StarForth }, }, "rom/starforth") I can share a minimal reproducible case (sources, build logs, QEMU output) off-list if that helps. Thanks in advance for any pointers to the “right way,” or to a maintained example I can follow. Best regards, R. A. “Bob” James (rajames440(a)gmail.com) Kubuntu 25.04 • amd64-plain • QEMU/VirtualBox • GRUB2 boot targets

2 1

Question about SMC filtering in smc_user.cpp on ARM64
by Gravel Yuan 25 Jul '25

25 Jul '25

Hello all, I'm currently working on integrating OP-TEE support on the ARM64 architecture within the L4Re framework, specifically focusing on cryptographic operations such as encryption and decryption. While reviewing the implementation, I noticed that in fiasco/src/kern/arm/smc_user.cpp, non-fast SMC calls are explicitly filtered out with the following check: // only allow fast callsif (!(r0 & 0x80000000)) return commit_result(-L4_err::ENosys); I'm trying to understand the rationale behind this design decision. Was it primarily driven by real-time performance requirements, or are there other considerations？ Additionally, as OP-TEE often uses *yielding calls* for certain operations, do you think it would be appropriate for us to consider extending the kernel to support such calls? We would appreciate any insights or recommendations you can provide. Best regards,

2 1

L4Re: MIPS SMP cache initialisation may be broken for some CPUs
by Paul Boddie 20 Jul '25

20 Jul '25

Hello, Pushing on with my efforts to port L4Re to another MIPS-based SoC, I have been attempting to activate more than one CPU core. Although there is some support in Fiasco for the MIPS Coherence Manager (CM) and Cluster Power Controller (CPC), these technologies are not supported in this particular SoC, which is related to the JZ4780 used in the MIPS Creator CI20. However, the Platform_control abstraction (in src/kern/mips/platform_control- mips.cpp) does seem to provide some flexibility in the way secondary CPUs or cores may be started. It seems that even in situations where the CM is not available, the alloc_secondary_boot_code method will assemble a bootstrap routine from snippets including one, _tramp_mp_cache, that initialises the caches. Unfortunately, it appears that this cache initialisation code does not work on this particular SoC. The method used by_tramp_mp_cache is the familiar one where the cache tags are invalidated for all cache index entries using the Index_Store_Tag operation for each cache type. This is supposed to work on any MIPS CPU, but through some tedious troubleshooting, I discovered that it does not work for the data cache. If the data cache variant of the Index_Store_Tag operation is performed for a range of addresses starting from the base of KSEG0, I found that some kind of side-effect would occur, possibly affecting the rather critical addresses in that range. This would prevent Fiasco from continuing to start up, and things like timers and the UART would not function, although the processor was not halted and would still run code, illuminating LEDs as a last-resort debugging tool. There is some preliminary support for this SoC, as well as the JZ4780, in Linux and it seems that instead of using Index_Store_Tag, the tag records are explicitly invalidated and updated. However, it also seems to be the case that caches can be invalidated using Hit_Invalidate. Changing the cache operations in _tramp_mp_cache to use this invalidation operation in its two variants appears to work, avoiding the problems described above. Does anyone have any thoughts or recollections about this cache initialisation routine? On the topic of actually starting secondary cores, this SoC has its own set of registers for resetting cores, interrupt control, mailboxes, and so on. I have developed a fairly simple abstraction that performs similar core bootstrapping work to that of the Cm abstraction (in src/kern/mips/cm.cpp). I then extend the Platform_control abstraction so that it will call the alloc_secondary_boot_code method, followed by the appropriate method to start the secondary cores. Is there any documentation for the SMP architecture in Fiasco and L4Re? I note that interprocessor interrupts (IPI) are one element that I might need to support, probably using the mailboxes. Thanks in advance for any advice or feedback that may be given! Paul

2 2

Subject: Introduction – StarshipOS: A gForth/JVM Hybrid on L4Re
by Robert James 13 Jul '25

13 Jul '25

Hello everyone, My name is Rob James, and I wanted to introduce myself and an OS I’ve been developing called **StarshipOS**. StarshipOS is a unique hybrid operating system built on top of the L4Re microkernel framework. It combines: - A Forth-based core powered by **gForth** - A lightweight persistent **object memory model** that completely replaces the traditional filesystem - Embedded **OpenJDK 21** services for high-level logic and tooling The system is non-POSIX by design. Instead of files, everything lives in a dynamic memory graph of interactive objects. You interact with your system through a Forth-based REPL that evolves and mutates this object universe in real time. No shell scripts, no /etc, no /usr — just memory objects and messaging. The ultimate goal is to make the **REPL the new shell**, and the **memory graph the new filesystem**. Here’s what’s already in place: - A full Maven-driven build system that compiles Fiasco.OC, L4Re, OpenJDK, and gForth from source - A `starship-maven-plugin` that automates ROMFS image generation and ISO boot layout coming soon: - A sandboxed REPL environment that boots directly into gForth and supports mounting JVM modules as interactive bundles - Early support for memory graph ACLs, entropy-based object lifespan, and “bubbles” — user-defined isolated memory regions Right now, I’m focused on integration, getting the system to boot into the gForth REPL with full JVM runtime support, and beginning to layer in userland services via custom dictionary words. Source is available (in-progress) here: 👉 **https://github.com/rajames440/StarshipOS** I’ve been programming since the 1970s, mostly in userland, and I’m diving deep into kernel space and L4 internals for the first time. I’d love to hear from others doing low-level work on L4Re, especially anyone who's extended the build system or tackled non-POSIX boot flows. Thanks again to everyone who’s contributed to L4Re and Fiasco.OC — it’s a hell of a foundation to build a new kind of OS on. All the best, Rob James

2 1

L4Re: Why was EXTERN_C_BEGIN/END replaced?
by Paul Boddie 23 Jun '25

23 Jun '25

Hello, Taking the opportunity to use a newer snapshot of L4Re, I notice that EXTERN_C_BEGIN and EXTERN_C_END now cause errors like this: error: unknown type name ‘DO_NOT_USE_EXTERN_C_END_ANY_MORE__USE__END_DECLS’ The commit introducing this behaviour seems to be this one: https://github.com/kernkonzept/l4re-core/commit/ e04b50e0e4f7c7a3316a2d8b658db6d81bd3e88d It would appear that throughout L4Re, a mass renaming has occurred from these symbols to __BEGIN_DECLS and __END_DECLS. Was there a particular reason for what might seem like an arbitrary change? Paul

3 2

Upgrade issues. VM won't start.
by Richard Clark 23 Jun '25

23 Jun '25

Adam, So I have been using version 23.10.1, built as per the download page, and have gotten a couple VMs to ping eachother and give me a login prompt. I finally realized I was missing the virtio_switch package and grabbed it from github and put it where it is supposed to go. Of course, being a version mismatch now, it did not compile. I decide to bite the bullet and do an upgrade (always a mistake) and use the new build process given with the new website. That went smoothly! I install ham, run it, etc, everything builds, I update my local scripts and links to use the new environment variables instead of being hardcoded, and it all builds and looks good. Except that it doesn't run. The VMs get a memory exception and kick into jdb. I have not changed any of my .cfg or .list files. The VMs and ramdisks are untouched. My local (L4 native) processes start and appear to run. But the VMs crash for some reason. Even the device tree is unchanged. I also tried a newly built linux (as opposed to a prebuilt) and that failed as well. Is there some reason for this new crash between version 23.10.1 and the latest version from github? I've attached the VM startup output from both the old and new runs so you can take a look. I'm so close... I see the IP configuration parameter and how to set up lwip and virtio_switch.... Then my natives should be able to talk directly to my linuxes. Your help is greatly appreciated! Richard

6 17

Linux fails on startup looking for SMC
by Moshe Kravchik 22 Jun '25

22 Jun '25

Hi, I'm trying to set up a Linux running on uvmm with a HW passthrough. I added `zynqmp_firmware` to my DTS (it was required for the device I'm trying to pass). However, Linux fails to add the device and I see: vm-1 | [ 1.772078] ledtrig-cpu: registered to indicate activity on CPUs vm-1 | VMM[guest]: No handler for SMC call: imm=0 a0=c200003f a1=3f ip=ffff800080026884 lr=ffff800080dcdb04 vm-1 | VMM[guest]: No handler for SMC call: imm=0 a0=c2000001 a1=0 ip=ffff800080026884 lr=ffff800080dcdb04 vm-1 | [ 1.805957] zynqmp_firmware firmware:zynqmp-firmware: probe with driver zynqmp_firmware failed with error -22 >From the traces I added, the failure is in `zynqmp_pm_get_api_version`. How do I add SMC handling? Best regards, Moshe _______________________________________________ l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de

2 14

Re: Issue Rebooting Guest OS in UVMM: Invalid Capability Invoke
by Philipp Eppelt 12 Jun '25

12 Jun '25

Hi Stephen, I'm happy to hear that. In the future, please take care to reply to the list too, such that others can learn as well. :-) Cheers, Philipp Am 12.06.25 um 8:34 AM schrieb yy18513676366: > Hi Philipp, > > Thank you for your reply — it was truly helpful to me. > > > I believe I have identified the root cause of the issue. I had assigned full > permissions to all capabilities using :svr(), which included the L4_CAP_FPAGE_D > right. This permission caused kernel objects to be forcibly deleted. After I > adjusted the capability permissions to m("rwncs"), the problem was resolved. > > > I do not yet have a deep enough understanding of capabilities, their permission > flags, and the mapping process via l4_task_map. > > Regarding the restart procedure — it is actually quite straightforward. > According to the documentation, the L4Re::Parent::signal interface can be used > to terminate a running program. So I terminate uvmm first, and then restart it > using the ned script, just like at the beginning. In this way, the guest OS is > relaunched. > > > Through this process, I’ve come to appreciate the stability of L4Re. It is > reassuring to see that the crash of a single application does not affect other > programs. > > > Once again, thank you for your support and assistance. > > Best regards, > > Stephen.yang > > > > > > > At 2025-06-11 17:21:32, "Philipp Eppelt" <philipp.eppelt(a)kernkonzept.com> wrote: >>Hi Stephen, >> >>I don't quite follow your description, can you please show your ned script to >>help my understanding? >> >> >>Wrt 1.: To actively delete a kernel object, you need a capability possessing >>delete rights and call `l4_task_unmap()` featuring the delete flag or >>`l4_task_delete_obj()`. >>Otherwise, the kernel object gets deleted, when the reference count drops to >>zero, meaning there are no more capabilities holding a reference to this kernel >>object. >>An application can release its reference, but still possess the capability. Or a >>capability can be mapped to another application without increasing the reference >>count. >> >> >>To answer 2 and 3 I first need to understand your reboot workflow. >> >>Cheers, >>Philipp >> >> >>Am 10.06.25 um 10:27 AM schrieb yy18513676366: >>> Hello, >>> >>> I am currently conducting research using the L4Re system, and I am working on >>> implementing a mechanism to reboot a Guest OS managed by UVMM. >>> >>> In my setup, I run two Linux instances under UVMM. My goal is to reboot one of >>> them without affecting the other. >>> >>> To achieve this, I terminate the target instance by sending a signal using | >>> L4Re::Parent::signal|, and then I restart it using a Ned script to launch a new >>> instance of the same program. >>> When restarting, I reuse the capability that was created during the first launch >>> of the UVMM instance. >>> >>> However, during execution, the restarted program encounters an *"invalid >>> capability invoke"* error. >>> >>> >>> Upon investigation, I suspect this happens because |l4_task_unmap| was called >>> during the restart process, which likely removed kernel objects associated with >>> the original capability. As a result, the reused |cap_index| no longer refers to >>> a valid object. >>> >>> Based on this, I would appreciate your insights on the following questions: >>> >>> 1. >>> >>> Under what conditions are kernel objects deleted in L4Re? >>> >>> 2. >>> >>> In this rebooting workflow, how can we ensure that capabilities remain valid >>> or that their associated kernel objects are not prematurely unmapped or deleted? >>> >>> 3. >>> >>> If UVMM crashes during operation, how can we design a mechanism to ensure >>> system-wide stability and security? >>> >>> Thank you in advance for your valuable feedback! >>> >>> Best regards, >>> stephen.yang >>> >>> _______________________________________________ >>> l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de >>> To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de >> >>-- >>philipp.eppelt(a)kernkonzept.com - Tel. 0351-41 883 221 >>http://www.kernkonzept.com >> >>Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. >>Geschäftsführer: Dr.-Ing. Michael Hohmuth >> -- philipp.eppelt(a)kernkonzept.com - Tel. 0351-41 883 221 http://www.kernkonzept.com Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth

1 0

Issue Rebooting Guest OS in UVMM: Invalid Capability Invoke
by yy18513676366 11 Jun '25

11 Jun '25

Hello, I am currently conducting research using the L4Re system, and I am working on implementing a mechanism to reboot a Guest OS managed by UVMM. In my setup, I run two Linux instances under UVMM. My goal is to reboot one of them without affecting the other. To achieve this, I terminate the target instance by sending a signal using L4Re::Parent::signal, and then I restart it using a Ned script to launch a new instance of the same program. When restarting, I reuse the capability that was created during the first launch of the UVMM instance. However, during execution, the restarted program encounters an "invalid capability invoke" error. Upon investigation, I suspect this happens because l4_task_unmap was called during the restart process, which likely removed kernel objects associated with the original capability. As a result, the reused cap_index no longer refers to a valid object. Based on this, I would appreciate your insights on the following questions: Under what conditions are kernel objects deleted in L4Re? In this rebooting workflow, how can we ensure that capabilities remain valid or that their associated kernel objects are not prematurely unmapped or deleted? If UVMM crashes during operation, how can we design a mechanism to ensure system-wide stability and security? Thank you in advance for your valuable feedback! Best regards, stephen.yang

2 1

L4Re: MIPS syncICache seems to be broken
by Paul Boddie 09 Jun '25

09 Jun '25

Hello, I have been trying to get L4Re working on another MIPS-based SoC and found myself struggling to get the kernel to boot. Initially, I wondered about various exotic concurrency issues, particularly since the SoC has two cores (each with two threads, apparently), but I started to suspect that our old nemesis, cache management, was to blame. Anyway, to save you the long story, I had a closer look at the syncICache routine that resides in the bootstrap package/module: pkg/bootstrap/server/src/ARCH-mips/crt0.S It turns out that syncICache is ineffective due to an erroneous loop continuation test. Here's the offending code: 10: synci 0($a0) addu $a0, $a0, $v0 sltu $v1, $a0, $a1 bne $v1, $0, 10b nop Here, $a0 is the region start and $a1 is the region size, with $v0 being the cache line size. The above code is equivalent to the following: address = start; do { synci 0(address) address += linesize; } while (address < size); The address should, of course, be compared to start + size. So, cache entries may not be flushed, particularly later in regions and at higher addresses, omitting coverage even of the early kernel regions, making kernel execution very unpredictable and unreliable. Perhaps the larger caches make this fault more obvious on this particular SoC. In the startup routine in the bootstrap package/module... pkg/bootstrap/server/src/startup.cc ...there is a declaration for syncICache, along with code to flush the caches, introduced purely for MIPS. To test my suspicions, I wrote a C++ version of the routine with inline assembly language for the machine instructions, fixing the loop continuation test. This seemed to allow the kernel to boot and the system to start up as I originally expected. Would you like me to contribute this fix? I think that unless inline assembly is problematic for some toolchain choices, it might be clearer to maintain this code in C++ rather than entirely in assembly language, thus avoiding such faults in the first place. This problem may have been around since the introduction of MIPS support into L4Re, appearing first in r70 of the public Subversion repository from back in May 2016. Paul

2 2

Can't tcp into VM?
by Richard Clark 05 Jun '25

05 Jun '25

Hey Adam! I’ve gotten the lwip stack working, and two vms running, and the ramdisks expanded a little, and some test processes statically built so I can run them… and the results suggest a firewall in the way, but I don’t see a way to enable the port I want… So lwip stack native to l4re, ipaddr 192.168.1.100, Vm1 at 192.168.1.2 Vm2 at 192.168.1.3 The vms can ping eachother. The vms can ping the lwip stack. Vm1 can establish a tcp connection TO the lwip stack. (and send packets!) Lwip cannot establish a tcp connection TO vm1. I would have tweaked the firewall, but I don’t see one, or any firewall utilities, in your default ramdisks. Suggestions? How would I enable port 5000 from 192.168.1.100 (lwip) to be allowed into vm1? Worst case, I guess I could just start all the connections from the vm, but still, it would be nice to know why it isn’t being allowed. I think this is the last little piece I am missing, and then I can run demos for our customer! 😊 Thanks! Richard

2 2

Real time application
by agaku03＠gmail.com 28 May '25

28 May '25

Hello I am trying to load real time applications on the L4re hypervisor. I would like to make sure that each application has a set ram space and a specific core. I have followed some examples that are proposed but I cannot segregate the various applications correctly. Is it possible to have an example of how I have to configure or what I have to do to achieve this?

2 8

fail to build package with l4re snapshot
by Tianhao Wang 22 May '25

22 May '25

hi, I'm trying to build a new package following the instructions from the snapshot page [1]. However it fails (error message below). steps: 1. download / extract the l4re-snapshot-25.03.0 snapshot 2. make setup (for the ia32 target) && make the hello world qemu example works correctly 3. add a new package, following instructions from "Adding your own code" [1] (of course the path placeholders are modified) /tmp/myfirstpkg/Makefile ``` PKGDIR ?= . L4DIR ?= PATH/TO/SNAPSHOT/src/l4 TARGET = myfirstprogram SRC_C = main.c include $(L4DIR)/mk/prog.mk ``` /tmp/myfirstpkg/main.c ``` #include <stdio.h> int main(void) { printf("Hello!\n"); return 0; } ``` 4. and try to build it $ cd myfirstpkg $ make O=/PATH/TO/SNAPSHOT/obj/l4/x86 error output: [myfirstpkg] ... Building Dependencies path/to/src/l4/mk/binary.inc:396: *** /tmp/myfirstpkg/Makefile: 'stdlibs compiler-rt' in REQUIRES_LIBS in Makefile but not in Control file requires. Stop. make: *** [path/to/src/l4/mk/binary.inc:195: path/to/obj/l4/x86/ext-pkg/tmp/myfirstpkg/OBJ-x86_gen-std-l4f] Error 2 I attempted to add file `Control` to the package root conataining the following but it doesn't work. requires: stdlibs compiler-rt Am I doing anything wrong in adding a new package? Sorry for the newbie question, I'm learning L4RE :) cheers, wth [1] https://os.inf.tu-dresden.de/download/snapshots/ -- wth 220F 6A50 7BEF 8C33 3B4A 4404 99DE B3B4 1583 4AEF

3 8