- l4-hackers - example.com Site

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 19 May '25

19 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