l4-hackers

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

2 participants
2880 discussions

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

lwip/virtio-net examples?
by Richard Clark 20 May '25

20 May '25

Hi there! I've gotten two linux vms to come up and automatically set their IPv4 address and login for me. (l4vio_net_p2p) They can ping each other just fine. Now I would like to get them to talk to my l4Re-native server. I see an lwip library, and I see that it has a virtio backend that appears to connect lwip to the virtual network. What I can't seem to find is an example that uses it? I have one vm at 192.168.1.2, and the one at 192.168.1.3. I would like to assign my lwip virtio-net interface to 192.168.1.100, and of course have them all talk TCP and UDP to each other. I can handle lwip and sockets, I just have no clue how to get it configured and initialized under l4re. Any examples and/or helpful hints? .cfg files? modules.list? Code? Github link? Thank you for your time! Richard _______________________________________________ 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 2

Re: l4-hackers Digest, Vol 246, Issue 9
by Torsten Wierschin 19 May '25

19 May '25

Hi there! In my opinion, the problem discussed here can be solved quite well using yocto or buildroot or something else. If I ever find the time, I'd be happy to publish my yocto build environment for l4re. But maybe someone else will be faster? I'd like to thank you for the many very valuable tips posted here. Torsten Am Do., 15. Mai 2025 um 00:34 Uhr schrieb <l4-hackers-request(a)os.inf.tu-dresden.de>: > > Send l4-hackers mailing list submissions to > l4-hackers(a)os.inf.tu-dresden.de > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > l4-hackers-request(a)os.inf.tu-dresden.de > > You can reach the person managing the list at > l4-hackers-owner(a)os.inf.tu-dresden.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of l4-hackers digest..." > > Today's Topics: > > 1. Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > (Marcus Hähnel) > 2. Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > (Paul Boddie) > 3. RE: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > (Richard Clark) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 14 May 2025 16:52:48 +0200 > From: Marcus Hähnel <support(a)kernkonzept.com> > Subject: Re: Configuration, component and repository versioning (was > Re: Upgrade issues. VM won't start.) > To: Paul Boddie <paul(a)boddie.org.uk>, l4-hackers(a)os.inf.tu-dresden.de > Message-ID: > <c648158693b4e8f556b4d371f74e7751dce80e40.camel(a)kernkonzept.com> > Content-Type: text/plain; charset="UTF-8" > > On Mon, 2025-05-12 at 22:37 +0200, Paul Boddie wrote: > > On Monday, 12 May 2025 15:09:52 CEST Marcus Hähnel wrote: > > > > > > On Mon, 2025-05-05 at 11:25 +0000, Richard Clark wrote: > > > > > > > But that brings me to a bigger question. > > > > How do I fetch only Long-Term-Support or Fully-Tested-and-Blessed > > > > versions? Github is woefully lacking in proper version support. > > > > I can't send random untested code to my customers. > > > > > > All code we push to Github went through our internal QA process, running > > > compile checks for all our supported architectures as well as an extensive > > > test suite on different platforms and configurations. So from that point of > > > view I would say you can consider all code pushed to Github as > > > “Fully-Tested-and-Blessed”. > > > > I don't have a strong opinion about quality assurance for people wanting to > > provide solutions for paying customers, but I have personally wondered how I > > might successfully and conveniently reproduce repository configurations when > > creating new L4Re development environments. > > > > For example, if I decide to work on support for a new board, I might want to > > replicate the L4Re configuration I have been using for another board. Starting > > from scratch, it was possible to use the ham tool, but despite it apparently > > maintaining version details for the different repositories, it wasn't > > particularly clear how one might preserve or export that metadata for further > > use. > > > > I now see that there is another tool involved: > > > > https://l4re.org/getting_started/bob.html > > > > Although that doesn't seem to replace the ham tool: > > > > https://l4re.org/getting_started/make.html > > > > Naturally, one might say that this is the point at which anyone serious-enough > > about using L4Re would get in touch with Kernkonzept and start talking > > business, but such a lack of clarity tends to suggest that either there aren't > > particularly adequate solutions for such fundamental needs or that any > > adequate solutions that may exist aren't for people merely investigating or > > evaluating the technology. > > > > Again, it isn't my concern if there's a business decision involved that > > everybody feels comfortable with, and if there's a steady stream of interested > > customers that seems to justify such a decision, but I could easily see > > potential users going elsewhere if the answer to simple questions is "talk to > > us". Even in reasonably large organisations, hitting an approval barrier that > > "talk to us" or "register your interest" represents can be a strong > > disincentive, especially if other solutions exist. > > > > I accept that my opinion isn't important, however, since my own activities are > > confined to my own interests and driven by a general belief that L4Re > > represents a reasonable foundation for certain kinds of systems. That there > > isn't exactly much of a public community around L4Re could also be regarded as > > a disincentive for potential adopters, which is unfortunate. > > > > Paul > > Hi Paul, > > thank you very much for your thoughtful message — it's really appreciated. > > First of all: your opinion absolutely matters. The input from users like you, who engage deeply and share candid feedback, > helps us make L4Re better. While we are aware that L4Re is still quite niche and the community small, we want to support it > as best we can and would love to see it grow. > > I think you're raising a different, but equally important, point compared to what Richard was asking. My original response > focused on the idea of providing a fully tested release for a specific combination of software configuration and hardware, > which is understandably difficult for us to maintain as part of the open-source offering given our limited resources. > > Your concern — about being able to reproduce a known working state of your development environment — is much more > fundamental. You're right: this should be straightforward, and if it's not, then it's something we want to improve. Ease of > use and accessibility are important to us, and sometimes we’re just too close to the system to see where friction arises — > so thank you again for pointing this out. > > To clarify one key point: we don’t deliberately withhold features or usability improvements from the open-source version of > L4Re to push people into commercial contact. That’s not our business philosophy. In fact, that would go directly against > our goal of getting L4Re into more hands and making it easier to work with. > > Some of the convenience features — like release tagging — do exist in our customer repositories, but it’s more of a > workflow habit than a conscious decision to exclude them from GitHub. No one had brought up the need for that kind of > reproducibility in the open repo so far — and now that you have, let’s fix it. > > Would something like weekly tags on GitHub help you? For example, a tag like `l4re-2025-05-14` that you could use with `ham > checkout` to reproduce that specific state? > > Also, ham already supports pinned revisions in the manifest (`revision` attribute in `project` tags), so you can share a > complete and reproducible state that way as well. But I agree that this could be made more convenient. > > One possible improvement could be a `ham create-pinned-manifest` sub-command that generates such a manifest from your > current state. That’s not trivial — it would require resolving different remotes and checking that all commits are actually > reachable in one of the remotes — but it’s definitely doable. If you're interested, feel free to open a proposal or even an > issue on the ham GitHub repository — we’d love to hear your thoughts or collaborate on a solution. > > Would any of these ideas help in your workflow? Do you have something else in mind? We're always happy to improve L4Re > together with the people who use it. > > Best regards, > > - Marcus Hähnel > Principal Engineering Lead > > > -- > +++ Register now for our workshop “Get to know L4Re in 3 days” on October 28–30. Learn to design and deploy secure system > architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++ > > --- > > Kernkonzept GmbH > Sitz: Dresden > HRB 31129 > Geschäftsführer: Dr.-Ing. Michael Hohmuth > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 14 May 2025 22:01:08 +0200 > From: Paul Boddie <paul(a)boddie.org.uk> > Subject: Re: Configuration, component and repository versioning (was > Re: Upgrade issues. VM won't start.) > To: l4-hackers(a)os.inf.tu-dresden.de, Marcus Hähnel > <support(a)kernkonzept.com> > Message-ID: <2728648.BddDVKsqQX@jason> > Content-Type: text/plain; charset="UTF-8" > > On Wednesday, 14 May 2025 16:52:48 CEST Marcus Hähnel wrote: > > > > thank you very much for your thoughtful message — it's really appreciated. > > Thank you for taking the time to respond! I didn't really expect such a > comprehensive reply, so it is much appreciated. > > > First of all: your opinion absolutely matters. The input from users like > > you, who engage deeply and share candid feedback, helps us make L4Re > > better. While we are aware that L4Re is still quite niche and the community > > small, we want to support it as best we can and would love to see it grow. > > It is reassuring to hear that you take feedback into consideration, even from > those of us who are not directly contributing to your work or, indeed, your > business. > > > I think you're raising a different, but equally important, point compared to > > what Richard was asking. My original response focused on the idea of > > providing a fully tested release for a specific combination of software > > configuration and hardware, which is understandably difficult for us to > > maintain as part of the open-source offering given our limited resources. > > I completely agree that if someone is in need of something that requires an > investment of time and resources, then they should either invest their own > time and resources, which is effectively what I have done over the last few > years, or they should be prepared to compensate others for that work. Nobody > should be required to do something for someone else for nothing - there is > already too much of that happening in the open source world - not that any > such request was made, I should add. > > Productive access to specific hardware configurations has always been a > challenge for software environment developers, and the collaboration required > to deliver robust support for a given hardware platform can be difficult to > coordinate. Even with today's hardware, mostly inexpensive from a historical > perspective, there is still a substantial cost in developing the corresponding > software support. > > > Your concern — about being able to reproduce a known working state of your > > development environment — is much more fundamental. You're right: this > > should be straightforward, and if it's not, then it's something we want to > > improve. Ease of use and accessibility are important to us, and sometimes > > we’re just too close to the system to see where friction arises — so thank > > you again for pointing this out. > > > > To clarify one key point: we don’t deliberately withhold features or > > usability improvements from the open-source version of L4Re to push people > > into commercial contact. That’s not our business philosophy. In fact, that > > would go directly against our goal of getting L4Re into more hands and > > making it easier to work with. > > I think it is fine to encourage people to make contact and to discuss > opportunities, and I don't seriously believe that people are being herded in > the direction of commercial support, but any kind of obstacle or hurdle in the > independent evaluation of a technology can be dissuasive. Some evaluators are > more likely to move on and look at other things than to cultivate some kind of > dialogue. > > This doesn't only happen in a commercial context. On plenty of occasions in > academia, I saw researchers encouraging others to get in touch, in order to > work around deficiencies in the way they had communicated or published their > work. I also saw the long-term effects of this, where people could not account > for what they had published after only a few years, with this emerging when I > was actually making contact with them to try and distribute their originally > published data. > > Empowering other people as much as possible or practicable may eventually > return such favours. When I return to my own work after a substantial period > of time, it is almost as if I am just another person taking a look at it, too. > > > Some of the convenience features — like release tagging — do exist in our > > customer repositories, but it’s more of a workflow habit than a conscious > > decision to exclude them from GitHub. No one had brought up the need for > > that kind of reproducibility in the open repo so far — and now that you > > have, let’s fix it. > > I can understand that it can be easy to overlook. How many times has one seen > missing tags in public repositories because Git makes it easy to forget to > push them? I also understand that publicly tagging releases can make mistakes > difficult to rectify, but I suppose this is just another hazard of release > management, and eventually we all get used to making "patch" releases. > > > Would something like weekly tags on GitHub help you? For example, a tag like > > `l4re-2025-05-14` that you could use with `ham checkout` to reproduce that > > specific state? > > It might, but I think the challenge is then applying such tags to a large > number of repositories. Naturally, one can write scripts to synchronise all > those repositories, but isn't that what ham is supposed to achieve? > > Richard also mentioned various other packages that ham doesn't cover, and > having been working with the software for a long time now, there are still > various packages that I have needed to retrieve from the Subversion repository > for L4Re because they were never migrated to GitHub. I can understand that > those packages are no longer a focus, and I have even eliminated some of them > from my own environment, but they might still be used by the L4Re > demonstrations. > > > Also, ham already supports pinned revisions in the manifest (`revision` > > attribute in `project` tags), so you can share a complete and reproducible > > state that way as well. But I agree that this could be made more > > convenient. > > Unfortunately, I never discovered this, but I assumed that you must have a way > to capture the state of repositories in order to reproduce releases required > by customers. > > > One possible improvement could be a `ham create-pinned-manifest` sub-command > > that generates such a manifest from your current state. That’s not trivial > > — it would require resolving different remotes and checking that all > > commits are actually reachable in one of the remotes — but it’s definitely > > doable. If you're interested, feel free to open a proposal or even an issue > > on the ham GitHub repository — we’d love to hear your thoughts or > > collaborate on a solution. > > It is something I could consider working on, but it would be joining a long > list of other tasks. > > > Would any of these ideas help in your workflow? Do you have something else > > in mind? We're always happy to improve L4Re together with the people who > > use it. > > I think they would be helpful. Previously, with Subversion, one could request > a given release and get a versioned distribution of the software. The > disadvantages were the poor performance of Subversion and the awkwardness of > managing independent changes, as we all know. But that simplicity was also > very useful. > > Thanks once again for following up and giving my concerns your consideration! > > Paul > > > > ------------------------------ > > Message: 3 > Date: Wed, 14 May 2025 16:04:06 +0000 > From: Richard Clark <richard.clark(a)Coheretechnology.us> > Subject: RE: Configuration, component and repository versioning (was > Re: Upgrade issues. VM won't start.) > To: Marcus Hähnel <support(a)kernkonzept.com>, Paul Boddie > <paul(a)boddie.org.uk>, "l4-hackers(a)os.inf.tu-dresden.de" > <l4-hackers(a)os.inf.tu-dresden.de> > Message-ID: <PH1P110MB17256A3F2418A9467AC57D79FC91A(a)PH1P110MB1725.NAM > P110.PROD.OUTLOOK.COM> > Content-Type: text/plain; charset="utf-8" > > Marcus, > > I, for one, rather than having to learn yet-another-tool that doesn't quite do what I want, would rather that > you have a fully-blessed-and-tested release all rolled up in a tar (or zip) file for download. You could even have > a git repo just for the tar files. One caveat, being that it must contain ALL the repos and possible little pieces > that could possibly go with it. One thing I hate about git is sub-repos that get lost or are not pulled down and > cause severe headaches trying to match versions. Like lwip, or virtio_switch, or any of the other couple dozen > packages that don't get pulled down with the new ham build process. I'd like to be able to go to one place, > use a command I already know, and get a fully functional, fully populated, "blessed" version. You do have your > old downloads site with a tgz file, but even that doesn't contain all the packages any more. This is the frustrating part. > I need a way to get a snapshot of everything that could possibly go together in a release whether I need it or not, because > some day I will need it and then the version I need will no longer be available. So, not a "demo" or "example" > version, but a full-source-everything-including-the-kitchen-sink version. > > > Thank you for considering our opinions! > > > Richard > > > -----Original Message----- > From: Marcus Hähnel <support(a)kernkonzept.com> > Sent: Wednesday, May 14, 2025 10:53 AM > To: Paul Boddie <paul(a)boddie.org.uk>; l4-hackers(a)os.inf.tu-dresden.de > Subject: Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > > On Mon, 2025-05-12 at 22:37 +0200, Paul Boddie wrote: > > On Monday, 12 May 2025 15:09:52 CEST Marcus Hähnel wrote: > > > > > > On Mon, 2025-05-05 at 11:25 +0000, Richard Clark wrote: > > > > > > > But that brings me to a bigger question. > > > > How do I fetch only Long-Term-Support or Fully-Tested-and-Blessed > > > > versions? Github is woefully lacking in proper version support. > > > > I can't send random untested code to my customers. > > > > > > All code we push to Github went through our internal QA process, > > > running compile checks for all our supported architectures as well > > > as an extensive test suite on different platforms and > > > configurations. So from that point of view I would say you can > > > consider all code pushed to Github as “Fully-Tested-and-Blessed”. > > > > I don't have a strong opinion about quality assurance for people > > wanting to provide solutions for paying customers, but I have > > personally wondered how I might successfully and conveniently > > reproduce repository configurations when creating new L4Re development environments. > > > > For example, if I decide to work on support for a new board, I might > > want to replicate the L4Re configuration I have been using for another > > board. Starting from scratch, it was possible to use the ham tool, but > > despite it apparently maintaining version details for the different > > repositories, it wasn't particularly clear how one might preserve or > > export that metadata for further use. > > > > I now see that there is another tool involved: > > > > https://l4re.org/getting_started/bob.html > > > > Although that doesn't seem to replace the ham tool: > > > > https://l4re.org/getting_started/make.html > > > > Naturally, one might say that this is the point at which anyone > > serious-enough about using L4Re would get in touch with Kernkonzept > > and start talking business, but such a lack of clarity tends to > > suggest that either there aren't particularly adequate solutions for > > such fundamental needs or that any adequate solutions that may exist > > aren't for people merely investigating or evaluating the technology. > > > > Again, it isn't my concern if there's a business decision involved > > that everybody feels comfortable with, and if there's a steady stream > > of interested customers that seems to justify such a decision, but I > > could easily see potential users going elsewhere if the answer to > > simple questions is "talk to us". Even in reasonably large > > organisations, hitting an approval barrier that "talk to us" or > > "register your interest" represents can be a strong disincentive, especially if other solutions exist. > > > > I accept that my opinion isn't important, however, since my own > > activities are confined to my own interests and driven by a general > > belief that L4Re represents a reasonable foundation for certain kinds > > of systems. That there isn't exactly much of a public community around > > L4Re could also be regarded as a disincentive for potential adopters, which is unfortunate. > > > > Paul > > Hi Paul, > > thank you very much for your thoughtful message — it's really appreciated. > > First of all: your opinion absolutely matters. The input from users like you, who engage deeply and share candid feedback, helps us make L4Re better. While we are aware that L4Re is still quite niche and the community small, we want to support it as best we can and would love to see it grow. > > I think you're raising a different, but equally important, point compared to what Richard was asking. My original response focused on the idea of providing a fully tested release for a specific combination of software configuration and hardware, which is understandably difficult for us to maintain as part of the open-source offering given our limited resources. > > Your concern — about being able to reproduce a known working state of your development environment — is much more fundamental. You're right: this should be straightforward, and if it's not, then it's something we want to improve. Ease of use and accessibility are important to us, and sometimes we’re just too close to the system to see where friction arises — so thank you again for pointing this out. > > To clarify one key point: we don’t deliberately withhold features or usability improvements from the open-source version of L4Re to push people into commercial contact. That’s not our business philosophy. In fact, that would go directly against our goal of getting L4Re into more hands and making it easier to work with. > > Some of the convenience features — like release tagging — do exist in our customer repositories, but it’s more of a workflow habit than a conscious decision to exclude them from GitHub. No one had brought up the need for that kind of reproducibility in the open repo so far — and now that you have, let’s fix it. > > Would something like weekly tags on GitHub help you? For example, a tag like `l4re-2025-05-14` that you could use with `ham checkout` to reproduce that specific state? > > Also, ham already supports pinned revisions in the manifest (`revision` attribute in `project` tags), so you can share a complete and reproducible state that way as well. But I agree that this could be made more convenient. > > One possible improvement could be a `ham create-pinned-manifest` sub-command that generates such a manifest from your current state. That’s not trivial — it would require resolving different remotes and checking that all commits are actually reachable in one of the remotes — but it’s definitely doable. If you're interested, feel free to open a proposal or even an issue on the ham GitHub repository — we’d love to hear your thoughts or collaborate on a solution. > > Would any of these ideas help in your workflow? Do you have something else in mind? We're always happy to improve L4Re together with the people who use it. > > Best regards, > > - Marcus Hähnel > Principal Engineering Lead > > > -- > +++ Register now for our workshop “Get to know L4Re in 3 days” on > +++ October 28–30. Learn to design and deploy secure system > architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++ > > --- > > Kernkonzept GmbH > Sitz: Dresden > HRB 31129 > Geschäftsführer: Dr.-Ing. Michael Hohmuth > > > > > _______________________________________________ > 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 > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 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 > > > ------------------------------ > > End of l4-hackers Digest, Vol 246, Issue 9 > ******************************************

2 3

Re: Linux console?
by Adam Lackorzynski 16 Apr '25

16 Apr '25

Hi Richard, your dts has the 'l4vmm,vcon_cap = "uart";' enabled (not commented out), thus the 8250 UART emulation in uvmm looks for a "uart" capability which is not there and thus disables the virtual UART. Removing that line or commenting it out will make this work I believe as the standard capability will be used then. Adam On Mon Apr 14, 2025 at 11:57:32 +0000, Richard Clark wrote: > Adam, > > Yes the vm-basic.cfg is where I started. > > I am attaching a tgz file with two directories showing the two different outputs that I get when > trying to run hvc0 and ttyS0. Included are the config files, the ramdisk, and the dts as well. > > > Richard > > > -----Original Message----- > From: Adam Lackorzynski <adam(a)l4re.org> > Sent: Monday, April 14, 2025 12:49 AM > To: Richard Clark <richard.clark(a)Coheretechnology.us>; l4-hackers(a)os.inf.tu-dresden.de > Cc: Bud Wykoff <bud.wykoff(a)Coheretechnology.us> > Subject: Re: Linux console? > > Hi Richard, > > On Fri Apr 11, 2025 at 15:27:18 +0000, Richard Clark wrote: > > L4Re, > > > > I’ve been working with the examples and tweaking them for AMD64 > > (QEMU), and I’ve managed to get linux up and booting, reading the > > ramdisk, and even spawning a login process which kicks off /bin/sh and > > displays a # prompt. And that’s great, but that’s all it does. I can’t > > get any input to it. That’s using the device hvc0. Of course uvmm > > complains that there is no virtual console and warns that it might not > > work, so the software is at least not surprised! 😊 But when I try to > > use the device ttyS0, linux stops printing even before the login > > process tries to run. I don’t get any errors, but also no output. And > > I can’t seem to run the IO server because then linux won’t load at all (something about out-of-memory). > > > > I’m sure I’m missing some little piece of magic somewhere, but I can’t > > find any working examples. None of them have active logins (I had to > > add my own iniittab to the ramdisk). A little help connecting the cons > > service to my linux so I can get a real bash shell? Or running IO and > > connecting through that? > > Did you try to run for example the "VM-basic" entry that is there? That is supposed to be a minimal working example. > Please also provide the output from the system you're getting, that is helping understanding what's going on. > > > Thanks, Adam _______________________________________________ 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 6

L4Re running Chromium?
by Lonnie Cumberland via l4-hackers 14 Apr '25

14 Apr '25

Hi All, Hope that your day is going well. I am experimenting with ultra-lightweight object capabilities-based OS's and have only briefly in the past worked a little with L4Re as I had troubles getting it to run cleanly on my Intel NUC7 (x86_64) hardware due to some type of graphics problem. In any case, I am back to see if I can give it another go and would like to work toward building a type of ultra-lightweight Kiosk type system that might run Chromium web browser in full screen mode without any type of window manager straight from booting up. The project that I have in mind would only use and need a fullscreen web browser, and perhaps capabilities to run containers (docker or podman) perhaps so that I could run a local web server and some other things in the containers. Not sure if L4Re is able to handle all of this, but I wanted to ask, just in case. Thanks and have a great day, Lonnie _______________________________________________ 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

3 2

Using L4 to run multiple Linux VMs
by Hübner, Andreas 14 Apr '25

14 Apr '25

Hello L4 hackers, I'm currently evaluating whether we can use Fiasco/L4Re for some of our future projects and ran into some problems/questions that you might help me out with. The general idea is to isolate multiple Linux VMs running Debian/Ubuntu (unmodified kernel) on x86/amd64 hardware with L4Re. I already did most of the tutorials on the kernkonzept/manifest github wiki. (https://github.com/kernkonzept/manifest/wiki) There were some issues with the hardware I'm using, since it maps its BIOS to an address that L4 likes to use for page tables. (at least on amd64, x86 did work out of the box) I fixed it by adjusting the base address in the linker script. (Hopefully, this should not have any bad side effects on L4.) First question: In the VM tutorials, I always see the use of kernel image + cpio ramdisk in the startup code. Is this also applicable if I want to use a full-fledged Debian/Ubuntu installation? The guest system should also be able to modify the installation. (i. e. run apt-get upgrade etc.) Second question: The general architecture for the VM scenario seems to be Fiasco/L4 -> uvmm -> Linux VMs. Is it also possible to use L4Linux as Host for the Linux VMs? My assumption would be, that it might be easier to use the Linux VMs from Linux instead of uvmm. (maybe with kvm/libvirt support?) Especially when it comes to passing the hardware to the VMs. Third question: This is a direct follow up from the last point. Passing the HW is the hard part for me. I'm not that familiar with device tree files yet and as far as I know x86/amd64 usually does not use device tree because it can auto-detect via PCI/ACPI. But it looks like uvmm/io does require device tree to pass the HW to the VMs even though L4 itself is detecting it via PCI/ACPI. Maybe I can pass the whole PCI bus, but then I would like to isolate at least some parts. For example VM 1 should only get one port of the network adapter and VM 2 should get another one. (exclusively) And while both VMs should be able to read the RTC, they should not be able to modify it. (or maybe only one of them) I know, it's not really a question, but maybe you can give me some advice on how best to approach this on x86/amd64 hardware. Fourth question: Does Fiasco/L4 support SR-IOV? I checked the code + commits and there seems to be some development in the last year, but not sure how "mature" it is. That's all for now, thanks for reading and I hope the questions are not too embarrassing/annoying. :) Best regards, Andreas Hübner Software Developer Business Fullfillment | Research & Development aconnic group OFFICE: 01157 Dresden, Am Lehmberg 54, GERMANY Phone +49 3722 7351-1010 E-Mail andreas.huebner(a)aconnic.com Web www.aconnic.com Court Munich Registration HRB 292019 Chairman of the Supervisory Board: Dr. Stefan Hagemann Executive Board: Werner Neubauer, Markus Königshofer aconnic AG (Munich), aconnic system Germany GmbH (Hartmannsdorf), aconnic service GmbH (Kornwestheim), aconnic sistemas de telecomunicaciones S.A. de C.V. (Mexico City), aconnic system Switzerland AG (Zurich), aconnic engineering AG (Zurich), aconnic carbonzero GmbH (Starnberg) are direct affiliates of the aconnic group. We refer to our data protection rules at: https://www.aconnic.com/privacy/ _______________________________________________ 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 3

Jump to page:

2025

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