This year’s retreat brought us to the Town of Tisá, Czech Republic, into a beautifully renovated Old Button Factory. The company arrived by different means of transport. Some with their private cars, some with a Carla bus and some by bike. Given that Tisá is ≈50km from Dresden, cycling there was a nice start.
The shopping crew took their time in the supermarket; if you buy food for 15 people for a couple of days, well, it takes time. Settling in, cooking lunch, starting with the research and discussion phase of the projects, hiking through the Walls of Tisá, hacking, dinner, hacking, Czech beer.
Tuesday: Early sunrise; later: Rain – vertical.
Due to the mixed weather conditions, we enjoyed the fireplace of our accommodation and the space to spread out through the house.
Wednesday: Morning: Snow; later: Rain – horizontal.
The fireplace grew on us every day.
Thursday: No rain, fine cycle weather.
Breakfast, couple of hours of cleaning up the code and later clearing the accommodation.
The projects we worked on spread from JDB manual, bug fixing and disassembler updates over uvmm topics like the monitor console and multiboot support to improvements of day to day work like QEMU boot times and building demonstrators.
The common rooms spiked discussions in dynamically changing groups on various topics and details, leading to a good mood for everyone. The good mood got even better by the puzzle games Hendrik brought.
What the colleagues say
I enjoyed the retreat very much. It gave me the chance to get to know my colleagues in an environment that is not our main office. I enjoyed the many conversations that I had and the friendly atmosphere. Although we did not have luck with the weather, we had two good hikes, to the Walls of Tisá and to the Hoher Schneeberg. I really enjoyed being out in fresh air and in the nature. Also, it gave many very good opportunities for photography. My colleagues turned out to be excellent cooks, and I enjoyed the meals they made. During the hours with rain, I was working on my project and I can report that I was able to finish it to my full satisfaction. It is my impression that my colleagues were very productive as well. Marcus even implemented an option ROM for QEMU that makes startup of my complex scenarios instantaneous. This retreat was a boost for my morale, and I am looking forward to having a retreat next year as well.
I just recently joined Kernkonzept for an internship, so the L4Re::Treat<2019> was the perfect opportunity to get to know all my colleagues. In retrospect I can say the three days did a whole lot in that regard.
My primary contribution was to work on the Fiasco kernel debugger to fix smaller problems and to update the built-in disassembler. I was also helping Yann to revise and update the kernel debugger manual.
I really appreciated being invited to the L4Re::Treat<2019> and getting the chance to meet everyone. It was very helpful to get to know something about everyone’s background and areas of expertise. Knowing the faces behind the names will certainly make collaborating together more enjoyable. Thanks to all who helped organize the accommodation, transport, food and activities.
My work topic was initially to update the JDB manual and collect in one place some tips, tricks and best practices for debugging. In the end, updating the JDB manual proved to be more than enough material for the retreat.
uvmm has had a monitoring console for a long time. However, it didn’t do much more than dumping the current register state. That’s rather boring. The goal for the retreat was to write a generic monitoring console, where all parts of the uvmm may register themselves and provide functions to show (and later even manipulate) their state.
Two major points need to be improved: console handling and command implementation. In terms of handling, the console needs to be equipped with proper readline/history support. There should be some help and potentially even command line completion.
The command implementation currently relies on some well-known hand-crafted functions. This needs to be replaced with a generic interface that every component or device in the uvmm may implement or not. When implemented, it may register itself with the monitor that then dispatches commands back to the device. This way, devices may even implement handling of sub-commands. Such a concept can be extended later to also allow state manipulation (e.g. write into guest memory or set breakpoints).
Jakub & Philipp
We researched different options for providing a boot loader for uvmm/x86:
- enabling uvmm to run GRUB 2,
- enabling coreboot,
- implementing multiboot1/2 in uvmm.
We decided that multiboot is the way to go forward, as it also lets us boot GRUB. The expected maintenance overhead is probably not larger than for the other options as the specification hasn’t changed in years.
Since Jakub is a HelenOS maintainer and HelenOS supports multiboot2, we chose to use HelenOS as a test OS. We split parsing the binary and providing the memory layout to the guest among us and got to work. The first boot was quite successful, but something was off with the memory: the guest thinks it has 4 zettabyte? That’s beyond odd. After some time well spent on debugging, we found the issue in HelenOS: some position pointer for the parsing was off by two bytes, which lead to a failing size check, which lead to the command line being interpreted as memory entry. Whoopee daisy.
This is already fixed upstream.
So what’s with GRUB, you ask? Well, we noticed something on the last day. GRUB expects to be booted with multiboot1, so there is still some work to do.
Christian & Marcus
QEMU boot time on x86/amd64 is slow and here is why: Seabios is QEMU’s bios implementation for x86 and it tries different boot methods (HDD, CD-ROM, floppy, ROM). For the QEMU make target it ends up using multiboot by loading the multiboot.img ROM. This in turn loads all required images (multiboot header structure, initial kernel and all modules) with IO-port reads into the guest’s RAM. It does this byte by byte and this is really slow.
Another complication on x86/amd64 is that it uses unstripped binaries by default which massively increases the amount of data required to transfer. On ARM we always create an ELF binary image (containing all required images/modules) which is stripped beforehand. On x86 those images/modules are specified on the command line. A quick comparison showed ≈5MB (ELF image) vs ≈60MB (unstripped data).
To fix those problems, we have basically three options:
- Strip all binaries by default.
- Create/use the ELF image type on x86/amd64 also all the time like we do on ARM.
- Fix the QEMU multiboot firmware by using DMA instead of IO access similar to what was done for linuxboot.img.
We explored all three variants. The most notable change is the update to the QEMU multiboot firmware where we rewrote the port IO data transfer method to use DMA just like the LinuxBoot firmware. This made the QEMU boot nearly instant on x86/amd64 and a lot of colleagues really happy.
Diego, Hendrik, Marius & Toni – Or: The Formal Methods Team
The formal methods team spent its time at L4Re::Treat<2019> on a prototype of
a model for L4Re. We wanted to implement a suitable abstract representation of
the system state and some prototypic functions that can change that state. Of
course, these functions are based on real L4Re functions like
First we discussed the scope of our prototype. In order to keep the prototype simple, we focused on object capabilities and ignored other types of resources, e.g., memory capabilities.
Afterwards we started hacking a first prototype in Haskell. However, we were not very satisfied with this first implementation. Therefore we explored some other ideas and ended up with three different Haskell prototypes.
Meanwhile, one of our team members got a bit tired of the Haskell problems and started to write his own prototype in OCaml. So all in all we now have four prototypes and taught ourselves some lessons for a more sophisticated model we want to implement in the future.