l4-hackers

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

2 participants
2880 discussions

Is the L4Linux running as a Fiasco.OC server?
by Zeyu Mi 09 Mar '18

09 Mar '18

Hi all, I am studying the implementation of the Fiasco.OC and the L4Linux. I have searched on the Internet and many papers and documents record that L4Linux runs as an L4 server and any L4Linux user process is a new task, which has a new page table different from that of an L4Linux server. However, the experiment result seems to conflict with those documents. When I started a new program in the L4Linux shell and used "lp" command (show present list) in JDB, I noticed that there was one thread having "vcpu" state. But the resulted list did not contain any new thread or task which is related to the new program. I am very confused and wondering whether or not the implementation recorded in those papers or documents are wrong or obsolete? The experiment is based on "l4re-snapshot-2016082114". Thanks in advance for any explanation. -- Best Regards Zeyu Mi

3 12

Activating the sigma0 thread in the Fiasco kernel
by Paul Boddie 08 Mar '18

08 Mar '18

Hello, I've been trying to coerce L4Re and Fiasco.OC to work with the Ben NanoNote, which is related to the MIPS Creator CI20 that is (mostly - see earlier discussions) supported by this software. There are a few challenges involved, such as avoiding MIPS32r2 instructions that the NanoNote's SoC doesn't support (JZ4740 in the NanoNote versus JZ4780 in the CI20), and positioning things appropriately to avoid upsetting the installed bootloader. Since I last posted anything about this, I've managed to get Fiasco to go about its bootstrapping business, proceeding from the bootstrap package, entering the kernel, running kernel_main, doing various initialisation tasks, enabling interrupts, and ending up in the init_workload method where a sigma0 thread and a boot thread are created and activated. It is at this point that I seem to have encountered a particularly stubborn problem: how to get the sigma0 thread to activate and return control to init_workload for the boot thread to be activated, then going on to finish what little remains of the bootstrapping process. Strangely, the boot thread has no difficulty in being activated and returning control if I put it first in the sequence, but sigma0 seems to cause something different to happen. Now, for this activation, it seems that the real action begins in Context::switch_cpu, where an exchange of stack pointers occurs and a branch is made to the Context::switchin_context method, with the old context presumably being made to resume after the branchpoint. As far as I can tell, both threads manage to set this up correctly. I see that the new context then causes Thread::user_invoke to be called, with execution proceeding via the ret_from_user_invoke routine and ultimately into the user task. Looking at the address to which the CPU will "return" to in user mode, all seems reasonable and consistent with the configuration of sigma0. However, one thing that baffles me somewhat is the way that interrupts are disabled in Thread::user_invoke. Given that the CPU ends up in the task in user mode, it would surely need some kind of exception or interrupt for the kernel to be re-entered, yet I don't see any operation that re-enables interrupts anywhere. Maybe this is the cause of my problem, but I don't understand how sigma0 would be different from anything else. I have needed to change some CPU-level operations to adapt the code to the earlier microarchitecture revision, but I don't think I've made any obvious mistakes, and I have seemingly figured out how to describe the interrupt system because for a while I couldn't get past the Delay::init invocation in the bootstrap process which relies on interrupts working. (Some comments in the code would have helped me guess what numbers to use in certain invocations.) Does anyone have any thoughts or guidance about what I should be looking at? Thanks in advance and sorry for the wall of text! Paul

2 6

Fiasco.OC development version available on github
by Matthias Lange 22 Feb '18

22 Feb '18

Hi, Kernkonzept proudly announces the availability of a development version of the Fiasco.OC microkernel on github [1]. It features a detailed history and will be updated regularly. Those interested in exploring the latest changes can amend the latest L4Re snapshot release (see [2]) with this development version. We plan to release development versions of the build system and selected userspace components in the weeks ahead. So, let us know what you think. Cheers, Matthias. [1] https://github.com/kernkonzept/fiasco [2] https://l4re.org/download.html -- Matthias Lange, matthias.lange(a)kernkonzept.com, +49-351-41 888 614 Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth

4 4

L4Linux performance vs hardware virtualization
by Bob Liu 12 Feb '18

12 Feb '18

Hi Folks, L4Linux.org mentioned: "Compared to monolithic Linux, there is a small performance tradeoff because of the µ-kernel architecture. However, the initial L4Linux has been somewhat optimized, and on L4/x86 it has a very acceptable slowdown of less than 4 % for any relevant load. " Any place can find more detail about the test? And I'm very curious the L4Linux performance vs "using hardware virtualization on top of L4", have you made any comparison before? -- Thank you! Bob

3 2

Microkernel and alumni meetup
by Matthias Lange 11 Feb '18

11 Feb '18

Dear friends of the microkernel, it's about time for another microkernel and alumni meetup to catch up on all the developments of the last 6 months. Let's meet for a beer or two. To find a date that fits the most people please visit https://dudle.inf.tu-dresden.de/Microkernel_Meetup/ and add your preferred day. Regards, Matthias. -- Matthias Lange, matthias.lange(a)kernkonzept.com, +49-351-41 888 614 Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth

2 2

MIPS Creator CI20 patches (again)
by Paul Boddie 06 Feb '18

06 Feb '18

Hello, I recently looked at the collection of patches accumulated when trying to get the CI20 support to a functioning state, and I think I've brought them up to date with the latest upstream repository version (r75). In doing so, I've also tried to break them up into distinct parcels of functionality so that the less interesting or less relevant patches can be ignored. A page describing the patches can be found here: http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html None of these patches have changed since previous discussions on this topic. The rdhwr instruction support I needed to add, for instance, is still done in MIPS assembly language, fitting in with existing support for another variant of that instruction. Anyway, I thought it might be useful to put them somewhere with a description for future reference. I've yet to get round to looking seriously at L4Re on the CI20 again and it isn't likely to happen now before the end of the year. Paul

2 13

Get instruction opcode + operands for page fault
by Josef Stark 04 Feb '18

04 Feb '18

Hi all, when a page fault occurs, does the Instruction Register contain the actual instruction that caused the fault or the previous instruction? In the former case, how can I access it? I need the opcode + the operands (like source/target registers). I already have the memory address that the instruction tried to access. I'm on ARM A9, so only load/store instructions can cause a page fault. I know that I could also look at the address where my IP is pointing to and get the instruction from there, but I'm wondering which way would be easier/better. Cheers, Josef

2 1

Build problems on i386 (Fiasco-OC.UX)
by Paul Boddie 30 Jan '18

30 Jan '18

Hello, More awkward news from Debian on i386! I was looking to build the "Linux Usermode Platform" variant of Fiasco-OC on i386 (well, Pentium 4) and encountered a couple of issues. Firstly, "struct ucontext" is mentioned in src/kern/ux/usermode.cpp but has been deprecated in favour of "ucontext_t". There are some User Mode Linux reports about this: https://lkml.org/lkml/2017/11/15/159 https://lkml.org/lkml/2018/1/25/522 A search-and-replace involving the two terms fixes the compilation error that otherwise occurs. Secondly, linking of the kernel fails due to symbol conflicts between the minilibc functionality and glibc: /usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu/libc.a(memcmp.o): In function `memcmp': (.text+0x0): multiple definition of `memcmp' libc.a(memcmp.o):/home/paulb/L4/UX-75/src/kernel/fiasco/src/lib/minilibc/memcmp.c:7: first defined here collect2: error: ld returned 1 exit status /home/paulb/L4/UX-75/src/kernel/fiasco/src/kern/ux/Makerules.KERNEL:35: recipe for target 'fiasco.debug' failed So, not knowing how best to deal with this, I relied on the --allow-multiple- definition linker option: https://gcc.gnu.org/ml/gcc-help/2009-09/msg00108.html I doubt that this is the right way to deal with it. Maybe GCC 6.4 (Debian 6.4.0-12) introduced some behaviour that is not compatible with the way this linking is being done. Both of the above issues are present in repository versions 74, 75 and 76 at the very least. Certainly, the first issue is not likely to be absent in earlier versions. Paul P.S. I have also been experiencing a build problem with L4Re on i386, but this will be described in another message.

2 2

Build problems on i386 (L4Re)
by Paul Boddie 30 Jan '18

30 Jan '18

As promised, my other error report... With Fiasco-OC built, I concentrated on building L4Re for i386, but this led to me encountering this rather frustrating error: [l4util] ==> Linking to shared libl4util.so /home/paulb/L4/UX-75/src/l4/mk/lib.mk:139: recipe for target 'libl4util.so' failed make[4]: *** [libl4util.so] Segmentation fault make[4]: *** Deleting file 'libl4util.so' ../../../../../mk/binary.inc:164: recipe for target '/home/paulb/L4/UX-75/src/l4/mybuild/pkg/l4re-core/l4util/lib/src/OBJ-x86_gen- l4f' failed This issue is present in repository versions 72 through 76. Again, I'm testing this with GCC 6.4 (Debian 6.4.0-12). I've not seen this at all when cross- compiling, either with the Debian or with Buildroot compilers. Paul

2 2

OS Engineers Wanted!
by Gernot Heiser 30 Jan '18

30 Jan '18

[Apology for the shameless ad, but might be of interest to some] Would you like to get paid for making the world more secure with seL4? I'm in charge of directing OS development for the newly-founded company Hensoldt Cyber. We will develop an integrated, highly-secure hardware-software solution, combined with secure production, aimed at changing the game in securing real-world embedded/cyber-physical systems. Needless to say, there will be close collaboration with the Data61 Trustworthy Systems team. We're now hiring engineers who will help us getting there. Specifically, we're looking for strongly-motivated people with practical experience in OS development, although there is flexibility with the degree of experience. Actual experience with L4 microkernels would be awesome. Place of work will be Munich (no remote work possible, sorry). You'll have to be prepared to obtain a German government security clearance (German citizenship is not a requirement for this). Interested? Please send me your CV. Gernot

1 0

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