l4-hackers February 2011

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

22 participants
19 discussions

MP Fiasco.UX
by Daniel Waddington - SISA 15 Feb '11

15 Feb '11

Hi, This may be a silly question, but can Fiasco.UX support multi-processing (i.e. SMP)? When I use JDB in Fiasco.UX I can only get one CPU even with MP configured in the kernel build. Thanks Daniel

2 1

build errors in fiasco kernel contained in l4re-core-2011021416 with JDB disabled
by Christoph Szeppek 15 Feb '11

15 Feb '11

Hi, when trying to build the kernel contained in l4re-core-2011021416 (from download page) with JDB disabled, I receive the following error messages: /prefix/l4re-core-2011021416/src/kernel/fiasco/src/kern/space.cpp: In static member function ‘static void* Space::Ku_mem::operator new(size_t, Ram_quota*)’: /prefix/l4re-core-2011021416/src/kernel/fiasco/src/kern/space.cpp:83: error: invalid use of undefined type ‘struct slab_cache_anon’ /prefix/l4re-core-2011021416/src/kernel/fiasco/src/kern/ram_quota.cpp:5: error: forward declaration of ‘struct slab_cache_anon’ /prefix/l4re-core-2011021416/src/kernel/fiasco/src/kern/space.cpp: In member function ‘void Space::Ku_mem::free(Ram_quota*)’: /prefix/l4re-core-2011021416/src/kernel/fiasco/src/kern/space.cpp:86: error: invalid use of undefined type ‘struct slab_cache_anon’ /prefix/l4re-core-2011021416/src/kernel/fiasco/src/kern/ram_quota.cpp:5: error: forward declaration of ‘struct slab_cache_anon’ This happens for ia32 pentium pro and arm integrator platform. With JDB enabled, both builds succeed. Christoph

2 1

None
by sasamy 14 Feb '11

14 Feb '11

Hello. I can not run fiasco kernel, version l4re-core-2011020417 # qemu-system-arm -kernel /home/sasa/fiasco/l4re-core-2011020417/src/l4/build/images/bootstrap.elf -serial stdio -m 256 L4 Bootstrapper Build: #2 Sun Feb 13 15:58:18 MSK 2011, 4.3.3 Scanning up to 256 MB RAM Memory size is 256MB (00000000 - 10000000) RAM: 0000000000000000 - 000000000fffffff: 262144kB Total RAM: 256MB mod04: 010d4000-010f5ad8: hello mod03: 010b2000-010d3ba0: l4re mod02: 01071000-010b16a4: moe mod01: 0105f000-01070538: sigma0 mod00: 01013000-0105e8e4: fiasco Moving 5 modules to 1100000 with offset ed000 moving module 05 { 10d4000-10f5ad8 } -> { 11c1000-11e2ad8 } moving module 04 { 10b2000-10d3ba0 } -> { 119f000-11c0ba0 } moving module 03 { 1071000-10b16a4 } -> { 115e000-119e6a4 } moving module 02 { 105f000-1070538 } -> { 114c000-115d538 } moving module 01 { 1013000-105e8e4 } -> { 1100000-114b8e4 } Scanning fiasco Scanning sigma0 Scanning moe --init=rom/hello Relocated mbi to [0x100e000-0x100e0d6] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0x2000 Regions of list regions [ 1000, 19bf] { 9c0} Kern fiasco [ 2000, 5cfff] { 5b000} Kern fiasco [ 90000, 9d193] { d194} Sigma0 sigma0 [ 140000, 18e2db] { 4e2dc} Root moe [ 1000000, 10123eb] { 123ec} Boot bootstrap [ 100e000, 100e1d3] { 1d4} Root Multiboot info [ 119f000, 11e2ad7] { 43ad8} Root Modules Memory API Version: (87) experimental Sigma0 config ip:00090000 sp:0100d744 Roottask config ip:00140120 sp:00000000 Starting kernel fiasco at 00001000 Cache config: ON Hello from Startup::stage2 Initialize page table Vmem_alloc::init() Vmem_alloc::TEST allocate zero-filled page... [0xefc01000] done free zero-filled page... done allocate no-zero-filled page... [0xefc02000] done free no-zero-filled page... done SERIAL ESC: allocated IRQ 1 for serial uart Not using serial hack in slow timer handler. Panic: __div0 Press any key to reboot. I have no experience, I'm not sure that everything is done correctly. #make qemu E=hello O=`pwd`/build MODULE_SEARCH_PATH=/tmp:/home/sasa/fiasco/l4re-core-2011020417/src/kernel/fiasco/build MODULES_LIST=/home/sasa/fiasco/l4re-core-2011020417/src/l4/conf/modules.list I tried to run on a real processor at91sam9m10 and got the same result (I think I wrote all the minimum necessary modules for it) Start SD card AT91Bootstrap... Image size: 0xf6000, load_addr: 0x71000000, ep: 0x71000000 relocating image to proper address, dst: 0x71000000, src: 0x72000040, len: 0xf6000 L4 Bootstrapper Build: #3 Sun Feb 13 14:10:12 MSK 2011, 4.3.3 Scanning up to 64 MB RAM Memory size is 64MB (70000000 - 74000000) RAM: 0000000070000000 - 0000000073ffffff: 65536kB Total RAM: 64MB mod04: 710d4000-710f5ad8: hello mod03: 710b2000-710d3ba0: l4re mod02: 71071000-710b16a4: moe mod01: 7105f000-71070538: sigma0 mod00: 71013000-7105e724: fiasco Moving 5 modules to 71100000 with offset ed000 moving module 05 { 710d4000-710f5ad8 } -> { 711c1000-711e2ad8 } moving module 04 { 710b2000-710d3ba0 } -> { 7119f000-711c0ba0 } moving module 03 { 71071000-710b16a4 } -> { 7115e000-7119e6a4 } moving module 02 { 7105f000-71070538 } -> { 7114c000-7115d538 } moving module 01 { 71013000-7105e724 } -> { 71100000-7114b724 } Scanning fiasco Scanning sigma0 Scanning moe --init=rom/hello Relocated mbi to [0x7100e000-0x7100e0d6] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0x70002000 Regions of list regions [ 70001000, 7000193f] { 940} Kern fiasco [ 70002000, 7005cfff] { 5b000} Kern fiasco [ 70090000, 7009d193] { d194} Sigma0 sigma0 [ 70140000, 7018e2db] { 4e2dc} Root moe [ 71000000, 710123eb] { 123ec} Boot bootstrap [ 7100e000, 7100e1d3] { 1d4} Root Multiboot info [ 7119f000, 711e2ad7] { 43ad8} Root Modules Memory API Version: (87) experimental Sigma0 config ip:70090000 sp:7100d744 Roottask config ip:70140120 sp:00000000 Starting kernel fiasco at 70001000 Cache config: ON Hello from Startup::stage2 Initialize page table Vmem_alloc::init() SERIAL ESC: allocated IRQ 1 for serial uart Not using serial hack in slow timer handler. Panic: __div0 Press any key to reboot.

2 5

can't interface I/O address Space
by Jason Philip 06 Feb '11

06 Feb '11

I writing small program to run on top the microkernel, but, I not sure how to interface the I/O space. I acquire I/O space using "L4_IoFpage()" call, but when I attempt interface it do not work. I try use pointer to I/O locations, but I not sure if this is a correct method. Can somebody tell me what is a correct method?

2 2

Fiasco.OC IPC performance
by Chen Tian 06 Feb '11

06 Feb '11

Hello, I am trying to compare the IPC performance between Pistachio and Fiasco.OC. I found the performances are almost the same for the Pingpong benchmark (I modified the one in Pistachio so that it can run with Fiasco.OC as well). I notice that if I turn off "tracebuffer" and "perfmon counter" switches when compiling Pistachio kernel, the IPC of Pistachio is much faster -- about 150x speedup for Pingpong! I tried to do the same thing for Fiasco.OC by turning off debugging related switches. However, I was not able to observe any performance improvement. I wonder if what config options that can dramatically affect the IPC performance for Fiasco.OC. Also, I will appreciate it if anyone could explain to me the major IPC implementation differences. Thanks, Chen

5 8

Can't access memory region
by Jason Philip 03 Feb '11

03 Feb '11

I need to have access to the VGA port and register. The register I need access in the range of 0x300 to 0x400 so I try getting a 1KB page from 300 onward, but it do not work. I suspect it do not work because it is I/O FPage and they have to align to (in this case 1kB) address. Could anyone help me access these port?

2 5

Questions on implementation details of capabilities
by Christoph Szeppek 03 Feb '11

03 Feb '11

Hello! I try to understand how capabilities are enforced by the Fiasco.OC kernel. From what I think I understood, capabilities are created in the kernel space area of an address space (which is the same in every address space) at Config::Caps_start. Each cap is identified by an index in this area and holds a reference to an object of type kobject_iface in its _obj attribute. This is the object this cap is controlling access to. Now I've got a few questions about further details. Where does the translation from address space local to kernel global cap id happen? How does the kernel know threads of which space are allowed to access which cap (mapdb?)? When a thread sends IPC, in which place of the kernel code do these caps get enforced / checked? BR, Christoph

2 1

Fiasco.OC internals
by Amadeo Cuadrado 03 Feb '11

03 Feb '11

Hello, My apologies if this question has been asked before in this list. What would be the most accurate doc that explains in detail the design and implementation of Fiasco.OC internals? Thanks in advance. Amadeo

2 1

Public release of seL4
by Gernot Heiser 02 Feb '11

02 Feb '11

NICTA and Open Kernel Labs have jointly released seL4. For those not aware of seL4, it is an L4 microkernel which is formally verified (meaning that the implementation is mathematically proven to conform to the specification). It is the world's first (and only) OS kernel that is formally verified in this strict sense. The public release includes the formal specification of the kernel (ARM version), kernel binaries for x86 and ARM, and a para-virtualized Linux running on top of seL4/x86. More about seL4: http://ertos.nicta.com.au/research/sel4/ NICTA download site: http://ertos.nicta.com.au/software/seL4/home.pyl Gernot

1 0

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 February 2011