l4-hackers April 2012

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

19 participants
24 discussions

Source of KVM-L4 ?
by Rolf Sommerhalder 14 May '12

14 May '12

Hello list, Is there any source code available of "KVM-L4", e.g. KVM which has been ported to L4Linux? There are some publications from TU Dresden which report about this successful port as KVM-L4. Is its source code available at all, or is it just hiding from search engines in some public repository or archive? Thanks, Rolf

4 12

[ankh+l4linux] Doesn't work
by Timur 03 May '12

03 May '12

Hi, after ifconfig eth0 up l4linux crashes with errors: -------------------------- l4lx_irq_dev_startup: creating IRQ thread for 66 (IRQ-cap 42d000) l4lx_irq_dev_startup: creating IRQ thread for 66 (IRQ-cap 42d000) l4linux | l4lx_thread_create: Created thread 433 (IRQ66) (u:b3000e00, sp:006c9ff4) l4linux | irq_thread: Started IRQ thread for IRQ 66 l4linux | wait_for_irq_message: IRQ 66 (42d) receive failed, error = 0x4 ------------------------ l4_is_invalid_cap(p->irq_cap) return false in wait_for_irq_message, but l4_irq_wait_u(p->irq_cap, &src_id, L4_IPC_NEVER, utcb) return L4_IPC_ENOT_EXISTENT. How can this be? -- Galiullin Timur

2 1

Re: Fwd: Running Fiasco.OC in Bochs
by Martin Unzner 29 Apr '12

29 Apr '12

Hi Norman, Björn told me about your problem because I write my Belegarbeit using a Framework which includes Bochs. I was not able to reproduce your exact error, but since I have experienced faults at the same stage of booting when I started with Bochs, my workaround might at least be worth a try. Using your setup, my Bochs instance hung up instead of reporting a double fault, but then again, everything worked when I disabled the PCI bridge. So maybe pci: enabled=0 in bochsrc or even omitting the --enable-pci parameter while configuring might help in your case. In general, I experienced that compiling Bochs with less configuration parameters usually produces a better emulator. Regards, Martin Am 29.04.2012 08:36, schrieb Björn Döbel: > Hi, > > Kannst Du dem Norman helfen? > > Björn > > -------- Original-Nachricht -------- > Betreff: Running Fiasco.OC in Bochs > Datum: Sat, 28 Apr 2012 21:14:37 +0200 > Von: Norman Feske<norman.feske(a)genode-labs.com> > An: l4-hackers(a)os.inf.tu-dresden.de > > Hello, > > for tracing/profiling purposes, I'd like to run Genode on Fiasco.OC in > Bochs. My prior attempts with the OKL4 and Pistachio kernels went fine. > However, when booting the setup with Fiasco.OC, I get the following > kernel message right at the start: > > Freeing init code/data: 28672 bytes (7 pages) > > DOUBLE FAULT! > EAX=ec7ff000 ESI=00000000 DS=0023 > EBX=fcdcf000 EDI=fcdcf170 ES=0023 > ECX=ec7ff000 EBP=f0060100 GS=0043 > EDX=ec7ff000 ESP=fcdcffbc SS=0010 ESP0=00000000 > EFL=00200246 EIP=f006592c CS=0008 > Return reboots, "k" tries to enter the L4 kernel debugger... > > Has anyone successfully used Fiasco.OC with Bochs before? If yes, I > would very much appreciate a known-good starting point for experimentation. > > For reference, I am using the following kernel configuration: > > > https://raw.github.com/genodelabs/genode/master/base-foc/config/x86_32.kern… > > My 'bochsrc' file looks as follows: > > display_library: x > romimage: file=/usr/local/share/bochs/BIOS-bochs-latest > megs: 128 > com1: enabled=1, mode=file, dev=serial.out > boot: cdrom > ata0-master: type=cdrom, path=var/run/demo.iso, status=inserted > mouse: enabled=1, type=imps2 > log: ./bochs.out > panic: action=fatal > vgaromimage: file=/usr/local/share/bochs/VGABIOS-lgpl-latest > vga: extension=vbe > pci: enabled=1, chipset=i440fx, slot1=pcivga > > The Bochs version is the official release 2.5.1 configured with the > following arguments: > > --with-x11 --enable-plugins --enable-pci --enable-clgd54xx > > Regards > Norman >

2 1

Running Fiasco.OC in Bochs
by Norman Feske 28 Apr '12

28 Apr '12

Hello, for tracing/profiling purposes, I'd like to run Genode on Fiasco.OC in Bochs. My prior attempts with the OKL4 and Pistachio kernels went fine. However, when booting the setup with Fiasco.OC, I get the following kernel message right at the start: Freeing init code/data: 28672 bytes (7 pages) DOUBLE FAULT! EAX=ec7ff000 ESI=00000000 DS=0023 EBX=fcdcf000 EDI=fcdcf170 ES=0023 ECX=ec7ff000 EBP=f0060100 GS=0043 EDX=ec7ff000 ESP=fcdcffbc SS=0010 ESP0=00000000 EFL=00200246 EIP=f006592c CS=0008 Return reboots, "k" tries to enter the L4 kernel debugger... Has anyone successfully used Fiasco.OC with Bochs before? If yes, I would very much appreciate a known-good starting point for experimentation. For reference, I am using the following kernel configuration: https://raw.github.com/genodelabs/genode/master/base-foc/config/x86_32.kern… My 'bochsrc' file looks as follows: display_library: x romimage: file=/usr/local/share/bochs/BIOS-bochs-latest megs: 128 com1: enabled=1, mode=file, dev=serial.out boot: cdrom ata0-master: type=cdrom, path=var/run/demo.iso, status=inserted mouse: enabled=1, type=imps2 log: ./bochs.out panic: action=fatal vgaromimage: file=/usr/local/share/bochs/VGABIOS-lgpl-latest vga: extension=vbe pci: enabled=1, chipset=i440fx, slot1=pcivga The Bochs version is the official release 2.5.1 configured with the following arguments: --with-x11 --enable-plugins --enable-pci --enable-clgd54xx Regards Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

Performance of l4_task_unmap call
by Chen Tian 26 Apr '12

26 Apr '12

Hi, I did a small test: a parent task first maps and then unmaps a page to its child. Both parent and child task are running on the same core. I found the execution is very slow and 99% time are spent on l4_task_unmap( L4_FP_OTHER_SPACES flag is used). After some investigation, I found the flag "need_xcpu_tlb_flush" in map_util.cpp:766 is set to true. My guess is that this flag controls the tlb of the cpu at which the child task is running. However, in my case, both tasks are running on the same core, setting this flag can have huge negative impact on performance. I am thinking to put a check before this statement: if (current_cpu() != space's CPU) set the flag to true. Is this correct? If so, how to get space's cpu? space->cpu() ? Thanks for the help. Chen

2 1

Bootfs got overwritten
by Haohui Mai 26 Apr '12

26 Apr '12

Hi, I'm encountering a problem where the memory region of BOOTFS of L4Re got overwritten. Interestingly, the page is overwritten by things in the bootfs. Here are the physical memory mapping set up by BOOTFS: ... BOOTFS: [2227000-23297b8] [C:506000] rtc BOOTFS: [232a000-26d5411] [C:507000] mag BOOTFS: [26d6000-2848a94] [C:508000] fb-drv BOOTFS: [129d000-129daa4] [C:509000] vandroid-x86.cfg BOOTFS: [126b000-126b3b7] [C:50a000] x86-legacy.devs … The page 0x2239000 (which belongs to rtc) is magically overwritten by the first page of x86-legacy.devs. I confirmed it with both JDB and QEMU monitor. I'm running the newest snapshot of L4Re / L4Android on top of the UP version L4.Fiasco kernel. What would be the best approach to debug the problem? is it there a way to mark the whole BOOTFS as read-only so that I can figure out what's going on? Thanks! ~Haohui

3 6

Re: Fiasco.OC development status
by Robert Campbell 24 Apr '12

24 Apr '12

I'm interested in userland changes and possible ports of libraries and frameworks. I'll definitely be focusing on the Fiasco.OC kernel. However, I'm at a crossroads with choosing the userland i.e whether to go with L4Re or Genode. IIRC, the port of Qt to L4Re or L4Env was version 3.x. Genode has a port of Qt 4.7.x. Genode has taken their development public So I am able to watch their activity. However, with L4Re I'm not sure what to expect in new releases bar what the publications might imply. If you are able to provide information on possible ports and update to existing ports then that would aid my decision and I would appreciate it. P.S

1 0

L4Android and L4Linux parallel on an i.MX53
by Tobias Fink 22 Apr '12

22 Apr '12

Hello List, for my bachelor project I'm trying to run Android and Linux parallel on an i.MX53 Board. While the first approach with KVM seemed not to be the right way to go L4 looks promising. While I found many interesting and helpful topics in this list I still have some questions. I tried to first build the "Hello World" example which worked fine but failed in building other examples because of not fulfilled dependencies (first to note io). I already checked out "l4linux_requirements". What else do I need? The board is a custom board with very little documentation. I have some Linux drivers for the connected hardware. Is it possible to use them with L4Linux or would I have to get/write drivers for L4 itself? Sorry about these very basic questions. I've just started working with L4. Regards Tobi

4 9

Windows in QEMU on KVM-L4
by Rolf Sommerhalder 22 Apr '12

22 Apr '12

Hi, In their paper [1], the authors mention that they were able to run 32-bit versions of Windows XP and 7, among other guest OSes, in KVM-L4 on AMD x86 processors with AMD-V extensions. Does anyone from the list happen to have an .iso around which boots on such an AMD machine and demonstrates the performance of Windows (any version will do) running in KVM-L4? Alternatively, I would be grateful for any recipe how to adapt a demo CD or Fisco.OC/L4Re build environment so that it allows to start a Windows image in QEMU/KVM on L4. So far, I have managed to install and to run Windows 7 Pro in a QEMU/KVM image on my Linux host. As this image is over 4 GByte by itself, plus QEMU with its dependencies, there is no way of just extending the ramdisk image in order to load and run it in L4Linux. After searching this list, I so far found two possible ways to proceed: a) Extended the ramdisk so that it mounts a disk partition /dev/hdaX, and then chroot to that mounted partition. Then try to launch the QEMU image from that new root. However, a previous poster here ran into a problem while trying this, and it is unclear to me if was able to overcome it [2]. b) Abandon the ramdisk and have L4Linux mount a disk partition as its root file system directly upon boot. This was tried in 2006 and it is unclear if it finally worked [3]. In both cases, I presume that the binaries in that partition (QEMU and its dependencies) must match the version of the L4Linux kernel (which is 3.0). My Linux build environment uses Ubuntu 10.04 LTS (which uses kernel 2.6.x). My only interest at this early stage of a quick Proof of Concept is just to get a feeling if a faithfully virtualised Windows run on top of KVM-L4 still performs reasonably well on a recent (Business-) PC, so that it is still acceptable to the average user. Previous results published suggested that real-world Linux applications incur (only) a 4..5% overhead when run on top of L4Linux, compared to running them natively on (bare metal) Linux. Now I would like to know if this surprisingly low overhead also continues throughout KVM-L4 with Windows as one of its "applications". Thanks in advance for any hints, Rolf [1] Virtual Machines Jailed - Virtualization in Systems with Small Trusted Computing Bases Michael Peter, Henning Schild, Adam Lackorzynski, Alexander Warg VTDS'09: Workshop on Virtualization Technology for Dependable Systems (Eurosys 2009 affiliated workshop) , March 2009 http://os.inf.tu-dresden.de/papers_ps/peterschild09_vtds_virtual_machines_j… [2] Using hard disk as root filesystem http://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg00851.html [3] Booting L4Linux/Fiasco with root=/dev/hda http://os.inf.tu-dresden.de/pipermail/l4-hackers/2006/002396.html

2 1

l4_task_cap_equal broken?
by Stefan kalkowski 20 Apr '12

20 Apr '12

Dear Fiasco.OC developers, while working with Genode on top of Fiasco.OC, I've encountered the following problem. When I transfer ipc-gates via ipc between tasks, it comes to the point where a task receives a gate it already owns. These duplicates are detected due to an additional identifier that is transfered together with the gate. To detect fraud (whether somebody has send an invalid gate/id combination) the received gate gets compared with the locally available one via "l4_task_cap_equal". Now, the problem is "l4_task_cap_equal" often fails even when both capabilities point to the same ipc-gate. The following code-snippet demonstrates this issue: ... tag = l4_task_cap_equal(L4_BASE_TASK_CAP, i->kcap(), rcv_cap); if (!l4_msgtag_label(tag)) { unsigned long id1 = l4_debugger_global_id(i->kcap()), id2 = l4_debugger_global_id(rcv_cap); printf("my_cap=%lx (id=%lx) rcv_cap=%lx (id=%lx)", i->kcap(), id1, rcv_cap, id2); if (id1 == id2) enter_kdebug("FAIL"); } ... This snippet is executed after a thread in the roottask received from another thread of the same task a capability via IPC. Thereby rcv_cap is the cap that was received via ipc and i->kcap() is the cap that was retrieved via the additional transfered identifier. When executed I get the following output: ... my_cap=20f000 (id=12) rcv_cap=205000 (id=12) --------------------------------------------------------------------- CPU 0 [00145e81]: FAIL [ entrypoint] jdb: The debugger's global id (here: 12) indicates that both capabilities reference the same object. Nevertheless, the equality test fails. Can you confirm that this is undesired syscall's behaviour, or do I miss something important? The attached kernel patch fixes the problem for me, but may introduce other problems (e.g.: not sure whether obj() returns always valid pointers). Regards Stefan

2 2

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 April 2012