- l4-hackers - example.com Site

Assertion failure error in kernel vgic interrupt processing
by nico 10 Apr '18

10 Apr '18

2 5

Entrypoint for user-space syscall instruction
by Zihan Yang 26 Mar '18

26 Mar '18

Hi, I'm trying to figure out the entry for 'syscall' in Fiasco, I already know that Fiasco will set MSR_STAR, MSR_LSTAR and MSR_CSTAR in Cpu::setup_sysenter. However, things don't seem right when I run a simple program of my own, which is compiled statically outside in Ubuntu with gcc 5.4.0. This program directly issues a single 'syscall' instruction (instead of the syscall() function), which is equivalent to getpid(). Here is the program, which is compiled with gcc -static -o syscall_single -O2 -std=gnu99 syscall_single.c -------------------- BEGIN --------------------- //syscall_single.c //gcc -static -o syscall_single -O2 -std=gnu99 syscall_single.c #include <stdio.h> void printres(unsigned long res) { printf("Done, id = %d\n", res); } int main() { asm volatile( "mov $39, %%rax\n" "syscall\n" "mov %%rax, %%rdi\n" "call printres" : : : "cc" ); return 0; } --------------------- END ------------------------ Since Fiasco has specified MSR_LSTAR, I expect every normal system call to goto the 'entry_sys_fast_ipc_c' in src/kern/ia32/64/entry-native.S, therefore I add such line at the beginning of entry_sys_fast_ipc_c -------------------- BEGIN --------------------- .extern unsigned long test_rax; entry_sys_fast_ipc_c: movq %rax, test_rax //mov rax to the global variable test_rax --------------------- END ------------------------ And I print this variable in 'sys_ipc_wrapper'. Now strange things happen, when I type './syscall_single' in the shell, test_rax is never 39 at any time! But yet it can get the right result, and there is output in 'dispatch_system_call' in l4linux side(manually added by me). My questions are (1) What is the entrypoint and actual path if a user program directly issues a syscall instruction? (2) I find dispatch_system_call judges whether there is a system call based on the 'trap_nr' field of thread_struct, does this mean it is implemented through exception? Thanks.

1 1

Ben NanoNote patches (MIPS/Ingenic JZ4720) and memory mapping issues
by Paul Boddie 16 Mar '18

16 Mar '18

Hello, Accompanying my patches for the MIPS Creator CI20 (Ingenic JZ4780), I have some patches that get Fiasco.OC booting on the Ben NanoNote (Ingenic JZ4720). Currently, I can get a task running that shows some data on the screen. More details about the Ben NanoNote can be found here: http://en.qi-hardware.com/wiki/Ben_NanoNote (It is a "palmtop" device from around 2010 that was made in fairly limited quantities but unfortunately didn't get the attention it deserved that might have seen follow-on models, and many more units, being made.) Unfortunately, the data I display on the screen isn't aligned properly. This isn't a fundamental problem since I was happily using the screen to emit bit patterns in order to debug the kernel while working to bring it up on the hardware. However, now, in my example task, I see what would appear to be a 9-pixel misalignment with the screen. Something like this, each digit being a pixel of a certain colour, with groups of ten sharing the same colour: 122222222223333333333...111111111 Although I suspect that this is some kind of peripheral initialisation issue, none of the device registers are any different from before, and I can even neglect to initialise most of them, keeping the configuration from the bootloader, and still see the problem. The registers I do have to change are the ones that tell the LCD peripheral where the framebuffer is, but I can check that the values I use are consistent with where I am storing screen data. So it makes sense to me to check whether there might be something related to L4Re or Fiasco.OC (and my modifications, of course) that could be causing this. In my task, I do the following: l4re_ma_alloc_align(fb_size, fbmem, L4RE_MA_CONTINUOUS | L4RE_MA_PINNED, 6) Here, the documentation indicates that the alignment will be 2**6 or 64 bytes, although it will in practice be page-aligned and thus 4096 bytes in my case. This, upon success, is then followed by this: l4re_rm_attach(&fb_vaddr, fb_size,L4RE_RM_SEARCH_ADDR | L4RE_RM_EAGER_MAP, fbmem, 0, L4_PAGESHIFT) And upon success, I obtain the physical address for the region: l4re_ds_phys(fbmem, 0, &fb_paddr, &fb_size_out) Both the virtual and physical addresses seem to be page-aligned. From my limited knowledge of the hardware, I cannot envisage a situation where writes to the physical memory would be offset, let alone wrapped in the way described above. But I suppose I could easily be unaware of other things that might be happening, and so it seems worthwhile to ask around. By the way, my patches are here: http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html I would certainly appreciate hearing any ideas about things I might have overlooked. Thanks, Paul

1 2

I got an issue, when testing command like this :qemu–system–aarch64 -kernel uimage -smp 2...
by Jiang qihong 14 Mar '18

14 Mar '18

The whole command , qemu–system–aarch64 -kernel uimage -M vexpress -a15 -cpu cortex-a57 -smp 2 -m256 --nographic The issue is that when running into shell, i didn't find two cpus. The parameter "-smp 2",didn't work. Does qemu support arch arm -v8 when using the parameter(-smp)? From jqh mobile phone.

3 2

How to show call path in backtrace with jdb?
by Zihan Yang 14 Mar '18

14 Mar '18

Hi all, I'm trying to debug L4Linux using jdb in Fiasco. I have added a breakpoint in a function(e.g, syscall_exit), and it did hit into jdb when I run. However, when I type 'bt' in jdb, it only prints the values in the stack, or worse, it sometimes couldn't print the stack. I have tried enabling L4_DEBUG_REGISTER_NAMES and CONFIG_FRAME_POINTER in L4Linux, and uncheck 'config without frame pointer' and 'generate inline code' options in Fiasco, but still it doesn't work. QEMU could be an option, but qemu debugs the whole system while I just want to focus on the L4Linux itself because I just want to figure out the call path of ret_from_fork and how does L4Linux stop the user dispatch loop, etc. Is there any way to show the the call path in jdb to assist the debugging work? By way, is there any doc describing the call path from fiasco to L4Linux, I know it is implemented with sysretq or iretq, but where is the entrypoint in L4Linux? For example, when I type 'ls /bin' in shell, it would finally go into L4Linux's function 'syscall_exit()', but how can I find the call path between them? If I can figure it out, maybe I just don't need to debug anymore. Thanks

2 1

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 11 Feb '18

11 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