l4-hackers

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

2 participants
2880 discussions

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

Linux console?
by Richard Clark 14 Apr '25

14 Apr '25

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? Thank you in advance! 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 1

Loading L4 after Uboot on ZynqMP
by mkravchik＠hotmail.com 10 Apr '25

10 Apr '25

Hello, I'm trying to run L4 on a Xilinx ZyncMP board. The board runs Uboot from ROM and then I tried to load L4 as described in https://l4re.org/bsp/zynqmp.html. However, loading a uimage fails, I'm getting an error: ZynqMP> fatload usb 0:1 0x0ffffc0 bootstrap_hello.uimage ZynqMP> bootm 0x0ffffc0 ## Booting kernel from Legacy Image at 00ffffc0 ... Image Name: L4 Image #8 Created: 2025-03-31 14:14:32 UTC Image Type: AArch64 Linux Kernel Image (uncompressed) Data Size: 1530680 Bytes = 1.5 MiB Load Address: 01000000 Entry Point: 01000000 Verifying Checksum ... OK XIP Kernel Image FDT and ATAGS support not compiled in ### ERROR ### Please RESET the board ### I tried to use rawimage, but there I get to the following problem: ZynqMP> fatload usb 0:1 0x1000000 bootstrap_hello-cfg.rawimage 2149176 bytes read in 151 ms (13.6 MiB/s) ZynqMP> go 0x1000000 ## S� L4 Bootstrapper Build: #15 Thu Apr 3 11:39:37 IDT 2025, 9.4.0 Scanning up to 2048 MB RAM, starting at offset 32MB Memory size is 2048MB (00000000 - 7fffffff) RAM: 0000000000000000 - 000000007fffffff: 2097152kB Total RAM: 2048MB Scanning fiasco -serial_esc Scanning sigma0 Scanning moe rom/hello.cfg Compressed modules: cannot decompress at 0x10a8000, try 0x11bc000 Uncompressing modules (modaddr = 0x11bc000 (backwards)): mod06: 0x126c000-0x1296b38: hello mod05: 0x126b000-0x126b080: hello.cfg mod04: 0x11e1000-0x126a118: ned mod03: 0x11bc000-0x11e0c40: l4re Loading fiasco found node 0 kernel info page (via ELF) at 0x3000 L4Re is configured for EL2 mode (virtualization / hypervisor) but got started in EL1 by the boot-loader. Please change your boot-loader to start L4Re in EL2 mode. I'm not sure how to proceed from here. The Uboot is loaded from the board's ROM and is running at EL2. Any help is appreciated, 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

3 5

L4re RAM/Flash usage and scheduling timing Info
by Eric Miniere via l4-hackers 28 Mar '25

28 Mar '25

Hello Everyone, I am looking for an estimate of the memory footprint to run the hypervisor L4RE on a quad Core ARM Cortex R52. Does it run directly from flash or it needs to be copied to run in RAM ? same question for Guests OS (ie FreeRtos)? What could be the minimal needed L4RE footprint for code and data ? Also if someone could share a rough idea of scheduling time for an ARM R52 running at 400Mhz ? or nb of cycle it takes to schedule ? Thanks _______________________________________________ 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

Trouble booting L4Re on PC hardware?
by Richard Clark 14 Mar '25

14 Mar '25

Hi! I've had much success building and running my applications in QEMU. No issues there. But now I've got myself some real hardware. Windows boots on it. Debian Linux boots on it. Linux even boots from the USB I create with rufus. No problems there. What I would like to do, is to take the system.iso image that normally runs under QEMU (x86_64), burn that to my USB stick (same way I put linux boot on there), and then boot the USB stick. The hardware will boot from the USB, and the image copy to the USB appears to work, since I've done that and booted linux. But I cannot seem to get the system.iso file to boot. I've tried UEFI boot, Classic boot, copy as UEFI image, and copy as DD image. It seems to ignore the USB drive and (by default) boot windows from the NVME drive. The device has no serial port. Just an HDMI screen with USB mouse and keyboard. It does have ethernet ports and I could try that, but it doesn't appear that the UEFI bios supports TFTP. How do I take my QEMU work and boot it on a real PC? Thanks! 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

3 2

How to L4Re on the S32G
by qiang xu 27 Feb '25

27 Feb '25

*Hello L4Re experts,* I would like to know how to run L4Re on the S32G. I couldn’t find any related documentation. I’m a beginner in this technical field, so could you provide friendly step-by-step instructions? Regards, Qiang _______________________________________________ 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

4 25

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