- l4-hackers - example.com Site

FPU state management in L4Fiasco.OC program
by Mai, Haohui 18 Apr '12

18 Apr '12

Hi, I'm writing a new OS kernel atop of L4Fiasco.OC. I'm having some difficulties to let my OS support user-level processes that uses floating-point instruction. So far, My OS closely follows L4Linux, it creates a new task for each user-level process, and marks as all threads of the task as alien thread to capture all page faults and exceptions. My OS works fines with page fault and syscalls. However, I'm confused with what I should do with floating-point exception (exception #7), which is issued to my kernel at the first time it tries to perform floating-point arithmetic. I tried to return to the user-level process with an empty message ( l4_msgtag_t tag = l4_msgtag(0, 0, 0, 0) ), or an empty message with L4_MSGTAG_TRANSFER_FPU (l4_msgtag_t tag = l4_msgtag(0, 0, 0, L4_MSGTAG_TRANSFER_FPU) ), but I had no luck. The user-level process immediately calls "int $0x3" and stops. I read through L4Linux's code and it seems it's doing similar thing, except that it did initialize the FPU state before asking L4 to transfer the FPU state to user-level process. Am I missing something? What's the recommend way of doing it? Your comments are highly appreciated. ~Haohui

2 8

shmc/l4shmnet improvements
by Stefan Fritsch 16 Apr '12

16 Apr '12

Hi, the attached shmc.diff fixes many bugs in shmc and adds some new functionality. l4shmnet.diff then uses this to implement a protocol that does not require one end to wait for the other end during boot, and that allows to set the link state up and down. The old protocol is still supported. The changes may be used under the MIT license (which is included in the include/shmbuf.h file. You can find the detailed changelog for shmc.diff below. The diff is on top of the diff I have sent in November. Cheers, Stefan Add include/shmbuf.h which implements the l4shmnet packet protocol, to be used by l4linux and others. include/shmc.h: - l4shmc_iterate_chunk(): New function to iterate over all chunk names - l4shmc_chunk_size(): change return value to allow returning an error - l4shmc_area_size_free(): New function to get remaining free space - l4shmc_area_overhead(): New function to get overhead not usable by chunks - l4shmc_chunk_overhead(): New function to get size overhead per chunk include/types.h: - Make l4shmc_chunk_desc_t members volatile to avoid races - l4shmc_area_t: add _size member for fast access - l4shmc_chunk_t: add _capacity member that stores the size outside of the shm area and is therefore safe from tampering by remote end shmc/include/internal.h: - l4shmc_chunk_ready(): need HW memory barrier - l4shmc_chunk_size(): Check for overflow - l4shmc_chunk_capacity() adapt to new _capacity member - l4shmc_chunk_consumed(): don't need a memory barrier lib/src/shmc.c: - l4shmc_create(): protect from integer overflows, initialize lock - l4shmc_area_overhead(): new function - l4shmc_chunk_overhead(): new function - next_chunk(): utility function that gets the next chunk, with proper sanity checks to avoid invalid memory access/loops if the other side is malicious - l4chmc_iterate_chunk(): new function - l4shmc_add_chunk(): Add sanity checks, use next_chunk(), initialize complete chunk struct properly before inserting into linked list - l4shmc_area_size_free(): new function - l4shmc_get_chunk_to(): Add sanity checks, use next_chunk()

2 4

Re: Can't get sender from l4_ipc_wait()
by Haohui Mai 16 Apr '12

16 Apr '12

Hi, Thanks for you suggestions. I did get sources from l4_ipc_wait() -- but I still cant map it back to the thread originating the IPC. I created an IPC gate for each task to receive page faults and exceptions, where I set the label of the gate to be my task identifier. I did get my task identifier back, but it seems there's no way to get my thread identifier since the source code of L4 Fiasco suggests that l4_ipc_wait() will only return the label of the IPC gate as the source. Setting the same pager for all threads in a single task seems a reasonable thing to do but obviously it lost the information for thread identifier. In order to recover this information, does it mean that I should create an IPC gate for each thread, setting its label to thread identifier in order to recover this information? Taking a step back, am I doing the right thing? If the answer is no, what would be the suggested architecture? Your comments are highly appreciated. ~Haohui On Apr 10, 2012, at 1:55 AM, Adam Lackorzynski wrote: > Hi, > > On Sun Apr 08, 2012 at 17:08:10 -0500, Mai, Haohui wrote: >> Can you elaborate a little bit? Some code skeletons would be quite helpful. >> >> I already created a new address space through l4_factory_task_create(), and >> my own kernel can serve all page faults / exceptions / IPC for that task. >> >> This is done by mapping the capability of my own kernel, which is its >> thread id, into the newly created task. Therefore, I assume that the IPC >> gate is set up. > > Are the other tasks trusted so that you can give out your own thread > cap? That's usually no good thing to do. > >> What else should I do in order to have my kernel getting the source of the >> IPC when calling l4_ipc_wait()? > > It's basically just l4_factory_create_gate, in the same way as > l4_factory_task_create. Create it with a label of your choice and > binding to the pager, and map it instead of the thread directly. > > > > Adam > -- > Adam adam(a)os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/

2 1

Questions about Vcon.
by Juwon.Song 13 Apr '12

13 Apr '12

Hello l4-hackers, I will try to use the Vcon of Fiasco. But I don't know about the usage of Vcon. I want to know more information about Vcon. If you have the more information and usage of Vcon, give me the data or examples. Thank you. Song.

2 1

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

12 Apr '12

Thank you Bjoern. Any idea when new release will be made and what changes and improvements to expect? > Hi Robert, > >> Is Fiasco.OC being actively developed(i.e new and on going research, >> new features) or is it just being maintained (small adjustments, bug >> fixes etc...)? > > yes, it's actively being worked on and our group uses it as the basis > for research projects. To get an (incomplete) overview of our research > work, you might want to look at our publications list: > http://www.inf.tu-dresden.de/index.php?node_id=1429 > > If you have more specific questions, feel free to ask. > > Cheers, > Bjoern

2 1

Bind irq to icu failed
by Shashi Sharma 09 Apr '12

09 Apr '12

Hi, I am trying to use e1000e driver in Ankh to bring-up intel's 82574L ethernet controller. But its unable to allocate interrupt and I cant figure out the source of the problem. Here is the ankh log: ------------------------------------------------------------------------ ankh | Initialized DDELinux 2.6 ankh | Initializing DDE page cache ankh | ddekit_pci_init ankh | pci bus constructor ankh | PCI: L4 root bridge is device 4e768 ankh | init_wq_head ankh | l4dde26_register_rx_callback: New rx callback @ 0x1000270. ankh | Softirq daemon starting ankh | <6>e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6 ankh | <6>e1000e: Copyright (c) 1999-2008 Intel Corporation. ankh | unimplemented: pci_set_master ankh | <3>0000:00:01.0: 0000:00:01.0: Failed to initialize MSI-X interrupts. Falling back to MSI interrupts. ankh | <3>0000:00:01.0: 0000:00:01.0: Failed to initialize MSI interrupts. Falling back to legacy interrupts. ankh | <6>0000:00:01.0: eth0: (PCI Express:2.5GB/s:Width x1) 0x14815cM ankh | <6>0000:00:01.0: eth0: Intel(R) PRO/1000 Network Connection ankh | <6>0000:00:01.0: eth0: MAC: 3, PHY: 8, PBA No: ffffff-0ff ankh | <6>Intel(R) PRO/1000 Network Driver - version 7.3.21-k3-NAPI ankh | <6>Copyright (c) 1999-2006 Intel Corporation. ankh | <6>net_namespace: 636 bytes ankh | open_network_devices() ankh | opening lo ankh | <6>device lo entered promiscuous mode ankh | set interface to promiscuous mode. ankh | opening eth0 ankh | <6>device eth0 entered promiscuous mode ankh | set interface to promiscuous mode. ankh | Thread 0xb0 for IRQ 10 ankh | Bind irq to icu failed with -2 ankh | claim_irq: failed to attach IRQ ankh | <3>0000:00:01.0: eth0: Unable to allocate interrupt, Error: -16 ankh | error opening eth0 : -16 ankh | Opened -16 network devices. ankh | lo IRQ: 0x00 MAC: 00:00:00:00:00:00 MTU: 16436 ankh | Registered @ registry. ankh | Gooood Morning Ankh-Morpoooooork! TID = 0x57 ankh | Creating session factory. ankh | Configuration: debug,promisc,device=eth0,shm=shm,bufsize=16384,phys_mac ankh | Debug mode ON. ankh | Using promiscuous mode. ankh | Device 'eth0' requested. ankh | SHM area 'shm' requested. ankh | Buffer size: 16384 ankh | Physical MAC requested. ankh | rom/ankh: /home/shashi/Desktop/L4/src/l4/pkg/ankh/server/src/session: 159: Ankh::ServerSession::ServerSession(bool, bool, bool, const char*, const char*, unsigned int. bool): Assertion `_dev' failed. --------------------------------------------------------------------------------------- I appreciate your help. Regards, Shashi

4 8

Can't get sender from l4_ipc_wait()
by Mai, Haohui 08 Apr '12

08 Apr '12

Hi, It seems that l4_ipc_wait() will always set the sender to zero. I tested it in example at /pkg/examples/sys/ipc/ipc_example.c, in the l4re-2011081207 snapshot. Here is the patch I applied to the file (to print out label): --- a/ipc_example.c 2011-08-12 00:20:36.000000000 -0500 +++ b/ipc_example.c 2012-04-05 17:29:24.844608359 -0500 @@ -84,6 +84,7 @@ continue; } + printf ("IPC from %lx, %d\n", label, label == 0); /* So, the IPC was ok, now take the value out of message register 0 * of the UTCB and store the square of it back to it. */ l4_utcb_mr()->mr[0] = l4_utcb_mr()->mr[0] * l4_utcb_mr()->mr[0]; And here is the result I got: ... vandroid| Sending: 4 vandroid| IPC from 0, 1 vandroid| Received: 16 ... So it seems that l4_ipc_wait() doesn't return the sender. I'm writing an OS on top of Fiasco.OC. This information is important for pager because it'll need it to figure out which page it'll map in. Do you have any ideas to fix it, or any idea to work around it (at least L4Linux works)? Your comments are appreciated. ~Haohui

2 1

Tracing only write page-faults
by Ivan Bludov 08 Apr '12

08 Apr '12

Hello. I want to trace all write page-faults from an application. I use the pager that wait for page-fault and maps the fpage to thread calling l4_ipc_send_and_wait setting L4_ITEM_MAP. For tracing only write page-faults I map fpage as L4_FPAGE_RO if it was read-pf and then I map the same fpage with L4_FPAGE_RW if the next write-pf occurs. (I mean I map the same fpage with the different flags twice). But an application doesn't continue run. Also I have tried to l4_task_unmap(L4_FP_OTHER_SPACES) this fpage before mapping it as L4_FPAGE_RW. It doesn't work. What should I use to change fpage's rights to L4_FPAGE_RW for fpage that is already mapped as L4_FPAGE_RO for an application? Ivan Bludov

2 1

support for multi-core in Fiasco.OC
by K M 05 Apr '12

05 Apr '12

I am using Fiasco.OC with VirtualBox and have successfully booted and run some demos. However, I am unable to get the kernel to use more than one core on my quad-core machine. I have enabled all 4 processors within the VirtualBox L4 machine, but when I run the "thread_migrate" example, only one CPU is ever recognized and used. What am I doing wrong? Thanks, Kevin

2 1

libgendep on Ubuntu 11.10
by Christian Helmuth 03 Apr '12

03 Apr '12

Hi, with current SVN (r38) I get the following error: gcc -fPIC -Wall -pedantic -g -m64 -c /plain/krishna/src/genode/genode.git/base-foc/contrib/l4/tool/gendep/deptrack.c -o /plain/krishna/build/genode.foc_x86_32/l4/tool/gendep/deptrack.64.o gcc -fPIC -Wall -pedantic -g -m64 -c /plain/krishna/src/genode/genode.git/base-foc/contrib/l4/tool/gendep/syscall.c -o /plain/krishna/build/genode.foc_x86_32/l4/tool/gendep/syscall.64.o mkdir -p /plain/krishna/build/genode.foc_x86_32/l4/tool/gendep/64 gcc -m64 -shared -Wl,-soname,/plain/krishna/build/genode.foc_x86_32/l4/tool/gendep/64/libgendep.so -ldl -o /plain/krishna/build/genode.foc_x86_32/l4/tool/gendep/64/libgendep.so /plain/krishna/build/genode.foc_x86_32/l4/tool/gendep/deptrack.64.o /plain/krishna/build/genode.foc_x86_32/l4/tool/gendep/syscall.64.o /usr/local/genode-gcc/bin/genode-x86-gcc: symbol lookup error: /plain/krishna/build/genode.foc_x86_32/l4/tool/gendep/64/libgendep.so: undefined symbol: dlsym The attached patch fixed the issue for me and I'd like to share it here ;-) Greets -- Christian Helmuth Genode Labs http://www.genode-labs.com/ · http://genode.org/ · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 3