- l4-hackers - example.com Site

PCIe handling in virt arm64
by Mohamed Dawod 20 Oct '24

20 Oct '24

Hello, I need to pass through the PCIe bus to Linux VM via io and uvmm servers. First, I generated the corresponding dtb file from qemu for *virt* machine to get the exact pcie device node. $ qemu-system-aarch64 -nographic -machine > virt,virtualization=true,dumpdtb=conf/arm_virt-64-full.dtb > $ dtc -I dtb -O dts conf/arm_virt-64-full.dtb Secondly, I copied the following nodes to my dts file (*pcie@10000000*, *intc@8000000* and *v2m@8020000*) exactly as they are in the original dts file. Finally, I modified the ned scripts as mentioned in the comments of the *pcie_ecam.cc* file. The issue is that there is no IO driver for the device *v2m@8020000 *which is responsible for msi-controller. This device is needed for the PCIe. The error logs : > VMM[PCIe ctl]: PCIe host bridge pcie@10000000 refers to invalid MSI > controller: MSI parent is not an MSI controller > VMM[HW PCI dev]: No MSI-X controller available for MSI-X device pci_bus[1] > (devid=1) > VMM[HW PCI dev]: No MSI-X controller available for MSI-X device pci_bus[2] > (devid=2). > VMM[ioproxy]: No corresponding IO resource for 'v2m@8020000'.reg[0] > (0x8020000-0x8020fff). > VMM[vm]: Device creation for v2m@8020000 failed. Disabling device. How can I pass through the PCIe device if there is no IO driver for the needed msi-controller ? Thanks in advance, Regards -- Mohamed Dawod *Software Engineer, *Cairo Egypt -- *Driving Innovation! Visit our website www.avelabs.com <http://www.avelabs.com/>*, to read Avelabs Confidentiality Notice, follow this link: http://www.avelabs.com/email/disclaimer.html <http://www.avelabs.com/email/disclaimer.html> _______________________________________________ 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

1 0

virtio disk handling
by Mohamed Dawod 09 Oct '24

09 Oct '24

Hello, I was reading this tutorial <https://github.com/kernkonzept/manifest/wiki/NVMeWithLinux> about using NVMe server with Linux guest and it works fine. Now I'm trying to apply the same tutorial but for arm64 instead of AMD64/X86_64. As expected, it didn't work because arm64 device tree blob/source doesn't contain the same *PCI* bus with the attached *virtio_disk* device node. Instead, virt-arm_virt-64.dts file contains only 2 VMM virtual devices for ARM guests : *virtio_uart* and *virtio_net*. I need a way to apply the same Tutorial (using NVMe server with Linux guests) for ARM64 instead of AMD64/X86_64. Any suggestions? Thank you, Regards -- -- *Driving Innovation! Visit our website www.avelabs.com <http://www.avelabs.com/>*, to read Avelabs Confidentiality Notice, follow this link: http://www.avelabs.com/email/disclaimer.html <http://www.avelabs.com/email/disclaimer.html> _______________________________________________ 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

sharing RTC device between 2 linux VMs
by Mohamed Dawod 03 Sep '24

03 Sep '24

Hi, I was trying to pass the RTC device from the host machine (qemu-arm46) to the guest machine linux VM on top of L4. and it was done successfully. Now I'm trying to share the same device between 2 linux VMs on top of L4. by duplicating the virtual device that describes the same physical device and also duplicating the virtual bus and passing one for each new vm. The issue if that one of the VMs is terminated because of the disability of binding the same IRQ as described in the screenshot below : [image: image.png] Please find attached all ned scripts I'm using for this experiment. Thank you, Regards -- Mohamed Dawod *Software Engineer, *Avelabs Egypt *Cell Phone : (+20) 1117311726* -- *Driving Innovation! Visit our website www.avelabs.com <http://www.avelabs.com/>*, to read Avelabs Confidentiality Notice, follow this link: http://www.avelabs.com/email/disclaimer.html <http://www.avelabs.com/email/disclaimer.html> _______________________________________________ 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

Fwd: Systems Meetup ("Mikrokernstammtisch") 16.05 (Do.) @ Cyberus Office
by Jan Bierbaum 02 May '24

02 May '24

FYI -------- Forwarded Message -------- Subject: Systems Meetup ("Mikrokernstammtisch") 16.05 (Do.) @ Cyberus Office Date: Thu, 11 Apr 2024 09:05:22 +0000 From: Philipp Schuster <philipp.schuster(a)cyberus-technology.de> Hallo alle zusammen, Wir von Cyberus würden gerne den "Mikrokernstammtisch" in Dresden wieder neues Leben einhauchen und ein gemeinsames Treffen mit der Systems Community in Dresden organisieren. Dafür möchten wir gerne unser Büro am 16.05 (Do.) von 18:00 bis 22:00 zur Verfügung stellen. Leitet diese Einladung gerne auch an einige Freunde oder Kolleg:innen weiter, wenn sie daran Interesse hätten. Wir stellen für das Meetup diverse Getränke bereit sowie einen Meeting-Raum. Hier die Fakten: - Donnerstag, 16.05, 18:00 - 22:00 - Systems Meetup, nicht nur Mikrokerne 🙂 - If necessary, we are happy to switch to english - 10-30 Leute (grobe Schätzung) - 2-4 Lightning Talks für Gesprächsstoff Lightning Talks: - 5 bis 10 Minuten - Mögliche Themen - Entwickler-Produktivität im Alltag - Testing setups - Coole Produkte/Projekte - knifflige gelöste Probleme - Demos - ... TODOs: - Bitte meldet euch ob ihr dabei seid + wie viele weitere Gäste kommen - Bitte meldet euch ob ihr Interesse habt einen kurzen Lightningtalk zu halten Hoffentlich bis bald! PS: Ich möchte euch noch darüber informieren, dass die ukvly Mailingliste die früher von Julian Stecklina betrieben wurde leider endgültig tot ist. Bei regem Interesse und Teilnahme, können wir gerne einen neuen Kommunikationschannel beim Meetup etablieren. -------------------------------------------------------- Philipp Schuster Software Engineer E-Mail: philipp.schuster(a)cyberus-technology.de Cyberus Technology GmbH Zwickauer Str. 46 01069 Dresden Deutschland/Germany Telefon: +49 175 431 6677 (Tor Lund-Larsen) Web: https://www.cyberus-technology.de/ Geschäftsführer: Tor Lund-Larsen Sitz der Gesellschaft: Dresden Amtsgericht Dresden, HRB 36573 _______________________________________________ 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

1 0

23.10.1 amd64 l4linux doesn't build
by Richard Clark 12 Apr '24

12 Apr '24

Hi! I'm doing microkernel evaluations for a US gov't contract to find a nice shiny new replacement for the dismal little l4 microkernel they've been using and failing with... Fiasco/L4/L4linux seems to be a wonderfully full-featured software platform that easily fits the bill. Separation/Capability microkernel, fully developed user space, l4-native linux, and even a vmm that runs a sandboxed linux. Latest build with snapshot 23.10.1 and l4linux 23.10.1 seems the amd64 l4linux is broken with issues in libelf.h, gelf.h, and elf.h. 32bit build seems to build ok. Still trying to get something up and running. I'll try 32-bit with qemu for now. I do need 64-bit to compile and run, so I would appreciate any info on how to fix the build issues. Thanks! Richard H. Clark _______________________________________________ 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 6

uClibc and pthreads
by Pascal Scholz 25 Jan '24

25 Jan '24

Hello to all L4-Hackers out there, I'm currently investigating the pthread Implementation used in L4Re for an university project. To me it seems, that it's using Linuxthreads as pthread implementation of the uClibc. Regarding this I got two questions, of which I would be very happy, if someone could answer them: 1) Is there a technical reason for L4Re still using the Linuxthreads implementation and not some kind of NPTL port or other implementations? 2) What uClibc is used exactly? Do you manage your own fork of uClibc and back port relevant patches of uClibc-ng? Or do you use a uClibc-ng with additional L4 patches? Or some completely other version? It seems that the uClibc version used diverged in 2014 from the original. This seems relevant to me as I wanted to check, which changes were done to make the uClibc work with L4 (in an attempt to generate some kind of a diff), so I might port them to another libc implementation. In my project I would like to replace Linuxthreads with some other pthreads implementation and measure the performance impacts of these changes, so the aforementioned questions seem relevant to me. Thanks in advance for you time! Kind regards, Pascal _______________________________________________ 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

Which C++ version does Fiasco use
by teclis High Elf 29 Dec '23

29 Dec '23

Hi, There are a lot of C++ versions. Is Fiasco L4Re compliant with the current C++20 standard? regards, _______________________________________________ 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

CfP: Microkernel and Component-based OS Devroom at FOSDEM 2024
by Martin Decky 15 Nov '23

15 Nov '23

Microkernel and Component-based OS Devroom at FOSDEM 2024 CALL FOR PARTICIPATION On-line version of this CfP: http://fosdem.microkernel.info/ The developers and users of several free and open source microkernel-based, unikernel-based and component-based operating systems will meet as part of FOSDEM 2024 [1] and will share a developer room. The devroom is currently looking for content in the form of talks and other activities related to microkernel-based, unikernel-based, component-based operating systems and similar areas. Possible topics of 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, device drivers) 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 * demos The devroom has been scheduled to Saturday February 3rd 2024 in the afternoon (Central European Time). This is a call for your participation. We kindly ask you to submit your proposals no later than on December 10th 2023 (End of Day, Anywhere on Earth). Please use the pretalx [2] web site to submit your proposals. Note that this is a new submission system and the user accounts from the previous submission system (pentabarf) have not been transferred. Make sure to select the Microkernel and Component-based OS as the track when submitting your proposal and include at least the following information: * title of your proposal * short abstract (one or two paragraphs) * duration (at least 15 minutes and no longer than 40 minutes) * your full name * your short bio You can specify your preferred time slot of your proposal and any other relevant information. The communication language of the devroom is English. Please note that the devroom has been allocated only a half of a day this year. Therefore the final decision on the duration of the talks will be made by the devroom organizers based on the number of accepted proposals. The official devroom schedule (along with the accepted talks) will be announced on December 15th 2023 on the devroom's mailing list [3] and the speakers will be notified via e-mail. The schedule will be published on the FOSDEM web site, too. About the Devroom Since the first Microkernel OS Devroom at FOSDEM 2012 [4], this devroom has been a part of each following FOSDEM (with slight variations of the name). The focus gradually widened to include component-based, unikernel-based and other operating systems. By now, it has become a somewhat institutionalized tradition for the open source operating systems community, a kind of "extended family meeting" and it is one of the places where microkernel and unikernel enthusiasts meet regularly. To this 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 every previous year, the devroom will offer the "stage" both to established community members and to newcomers. We like to select the talks in an inclusive manner, while staying true to the main technical topics (system-level software, broadly speaking) and creating a balanced and unbiased schedule. We would like to keep the quality bar of the devroom same as in the previous years. Presenting at FOSDEM implies that the recordings of the talks will be published under Creative Commons license by FOSDEM. By submitting a proposal, the speaker agrees to have the talk made available publicly indefinitely. For organizational purposes, we also need contact information of the speakers of accepted talks. Microkernel Dinner It has also become a habit that the devroom participants dine together somewhere in Brussels. The year 2024 will not be any different, so there is going to be a dinner on Saturday night. We will inform you about the exact arrangements later. About FOSDEM FOSDEM [5] 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 latest directions, 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 8000 developers annually at the ULB Solbosch Campus in Brussels, Belgium. The participation in FOSDEM is totally free, although the organizers gratefully accept donations and sponsorship. No registration is necessary. Attendees are expected to follow the FOSDEM's code of conduct [6]. Important Dates Recap * 2023-12-10: Deadline for proposal submission * 2023-12-15: Schedule published and speakers notified of acceptance * 2024-02-03: Devroom taking place Contact For any comments, questions and suggestions, please do not hesitate to use the devroom's mailing list [3] to contact the devroom organizers. The primary organizers of the devroom in 2024 are: * Martin Decky * Razvan Deaconescu References [1] https://fosdem.org/2024/ [2] https://pretalx.fosdem.org/fosdem-2024/cfp [3] https://lists.fosdem.org/listinfo/microkernel-devroom [4] https://archive.fosdem.org/2012/schedule/track/microkernel_os_devroom.html [5] https://fosdem.org/ [6] https://fosdem.org/2024/practical/conduct/

1 0

L4Re: stack allocation of moderately large arrays
by Paul Boddie 13 Nov '23

13 Nov '23

Hello, Having seen a problem recur in programs running in L4Re just now involving arrays of a relatively large size allocated statically in functions - about 100000 bytes or so - I was wondering if there are any implicit limitations with this form of allocation in L4Re. Is it possible that programs have a limited stack size and that the stack does not expand? Here is an example of the kind of code that causes an unhandled exception: uint32_t Spi_gpio::send_units(uint32_t bytes, const uint8_t data[], uint8_t unit_size, uint8_t char_size) { uint32_t chars = bytes / unit_size; int dc[chars]; And the exception looks like this: Unhandled exception: PC=0x1019ca8 PFA=0xfffd075a LdrFlgs=0x0 The actual cause of the exception is an access to an element in the dc array. When I eventually get back to my own experiments with initiating programs in L4Re - not involved with the problem reported here - I intend to look more closely at program stack allocation and expansion strategies, so I suppose this is an appropriate prelude to such work. Thanks for any guidance that might be offered, as always! Paul

2 1

L4Re: Input via UART fails with Ned involvement
by Paul Boddie 19 Sep '23

19 Sep '23

Hello, I have been trying to get some sensible behaviour from various programs running in L4Re that wish to read from standard input, hopefully using the UART, since standard output is successfully sent across the serial connection. However, it appears that Ned does something rather undesirable with the input stream. If I modify the hello example to use fgets and deploy it without Ned (the hello.cfg example in conf/examples), as long as some kind of serial initialisation has occurred, I can enter characters at the serial console and have the program read them. However, if I deploy the same code using Ned (the hello.cfg example in conf/examples), fgets repeatedly returns NULL. Strangely, if I follow the instructions in the L4Re documentation... https://l4re.org/doc/l4re_servers_ned.html#l4re_ned_interactive The ned-prompt program itself just prints "Cmd>" over and over again, failing to read anything. It is as if non-blocking I/O has been enabled, although ned- prompt appears to use readline, so I imagine that there is likely to be a somewhat different explanation. Attempting to enforce non-blocking input using fcntl in the hello example also does not help. Has anyone any suggestions as to why these things do not work? I have tried this on physical hardware as well as in QEMU. Thanks in advance, Paul

2 3