gmane.comp.micro-kernel.l4.l4ka.general

RE: virtual networking in l4ka::pistachio

Jan Stoess — 2008-05-08T06:36:48

Hello Ashish, There exist basically two approaches: One approach is based on the concept of reusing Linux drivers (for details, see the paper http://l4ka.org/publications/paper.php?docid=1208). In short, we bring up a dedicated driver VM (similar to Dom0) and then connect the Linux bridging and driver logic with the guest VMs by means of hand-written emulation and glue code. The other approach is to implement a native virtual switch and drivers based on L4's microkernel concepts (threads, address spaces, IRQ abstraction). The disadvantage here is the additional porting effort, the advantage is a substantially lower memory and CPU footprint compared to the heavy-weight driver VM approach. The afterburner currently implements both approaches for virtual networking, check out the directories l4ka-driver-reuse and l4ka-driver-native in the repository. -Jan -- Jan Stoess System Architecture Group University of Karlsruhe Phone: +49 (721) 608-4056 Fax: +49 (721) 608-7664 eMail: stoess< at >ira.uka.de

virtual networking in l4ka::pistachio

Ashish Bijlani — 2008-05-07T21:29:04

Hi, How is virtual networking implemented in pistachio? Can one VM ping another VM over a shared memory channel as in Xen? Thanks, Ashish

RE: SMP Scheduling

Jan Stoess — 2008-04-29T11:47:06

In my opinion, we should include that into mainline and - make it the default behavior for total-quantum preemptions - make it configurable for end-of-timeslice and other preemptions at runtime, e.g. via ThreadControl. -Jan -- Jan Stoess System Architecture Group University of Karlsruhe Phone: +49 (721) 608-4056 Fax: +49 (721) 608-7664 eMail: stoess< at >ira.uka.de

RE: SMP Scheduling

Espen Skoglund — 2008-04-29T11:10:11

[Jan Stoess] I did an implementation that used infinite timeout and required a reply fromm the scheduler as well. Also, I added support for IPCs upon all preemptions and/or preemptions due to end-of-timeslice. I'm not sure if Jan or other people wants support for this in mainline Pistachio. The modifications to support this sound trivial, but they require a bit of restructuring inside the kernel to avoid having several layers of nested IPCs (which consumes too much kernel stack space). eSk

RE: SMP Scheduling

Jan Stoess — 2008-04-29T08:40:32

That's correct except for the UP-IPC path, where the scheduler is shortcut in favor of a timeslice donation scheme. The SMP-IPC, path again uses the scheduler, however, since synchronization (e.g., via IPIs) is needed anyway. That's true with respect to the X.2 spec. The current implementation doesn't use timeout 0, however, as you can see in tcb_t::send_preemption_ipc(u64_t time) in kernel/src/api/v4/thread.cc. Afaik no-one has really used preemption messages in the original L4KA:Pistachio. I know of several prototypes addressing scheduling problems in L4, but no official version is available (yet). Regards, -Jan -- Jan Stoess System Architecture Group University of Karlsruhe Phone: +49 (721) 608-4056 Fax: +49 (721) 608-7664 eMail: stoess< at >ira.uka.de

Re: SMP Scheduling

Philipp Kupferschmied — 2008-04-29T08:27:03

Hello, let my try to answer those questions of which I think I know the answer ;-) As far as I know, this is correct. Nope, I think that's not correct. Threads are assigned to the CPU on which ThreadControl is executed and can be migrated afterwards using "Set_ProcessorNo", which is derived from the "Schedule" syscall. Or did I get your question wrong? I'm not sure about this, but it sounds reasonable. It is generally a good idea to offer at least one thread per service and CPU for reasons of parallelism and to avoid communication between threads on different CPUs. Perhaps [1] might also be interesing for you. Hope this helps, Philipp [1] Towards Effective User-Controlled Scheduling for Microkernel-Based Systems Jan Stoess ACM SIGOPS Operating System Review, Special Topics on Secure Small-Kernel Systems, July 2007 http://i30www.ira.uka.de/research/documents/l4ka/2007/stoess07ul4sched.pdf

SMP Scheduling

Julian Stecklina — 2008-04-29T01:28:10

Hello, I am porting Bastei[1], which is a new userland for the Fiasco microkernel, to Pistachio. The initial port is done and (minus some bugs) is working fine. As I am particularly interested in Pistachio's SMP capabilites, I am planning to add SMP-awareness to the Bastei system. At the moment, Bastei does not handle scheduling at all, which leaves me with a lot of possible paths to persue. But since my experience with L4 is quite small, I tried to collect some information about scheduling in Pistachio first to avoid basing this work on false assumptions (please correct me if I am wrong): - Threads have priorities. Threads in one priority class are served round-robin. Higher priority queues are served first. - A thread has a timeslice size and a "total quantum". Each time the thread is preempted (or calls L4_Yield), the time it has consumed is subtracted from the total quantum until it is depleted. At this point the thread's scheduler gets a preemption message. - Whether the preemption

RE: (nb) Marzipan on PPC ?

Jan Stöß — 2008-04-16T07:10:08

[mailto:l4ka-bounces< at >ira.uni-karlsruhe.de] On Behalf Of Antonin SUBTIL No it isn't available for PPC. I can't really answer how much work it is to port it, since "much" depends on the person(s) porting it. l4ka-resourcemon (aka marzipan) is mostly generic C-code which can be ported in a straight-forward manner. But surely you'll find a fair number of obvious and hidden assumptions that the system runs on IA-32 when doing so. -Jan -- Jan Stoess System Architecture Group University of Karlsruhe Phone: +49 (721) 608-4056 Fax: +49 (721) 608-7664 eMail: stoess< at >ira.uka.de

(nb) Marzipan on PPC ?

Antonin SUBTIL — 2008-04-15T09:27:43

Hello, I've read Marzipan is not available on PPC, but can be. Is it available??? If not, would it need a lot of work to port it on ppc? "Supported Systems The resource monitor supports IA32 and IA64 systems. The other platforms of L4Ka::Pistachio's rich platform support can be enabled as necessary." thanks

RE: Afterburner-Wedge Compile Error - Need Help!

Jan Stöß — 2008-04-14T10:05:24

It seems that you're using an older version of afterburner (newer ones have L4KA_VT renamed to L4KA_HVM). Please update your revision accordingly. Keep in mind that L4/HVM and afterburner/HVM are *development* branches, so don't expect anything to compile smoothly out of the box. Also check the branches for changes regularly (http://hg.l4ka.org/exp/ provides RSS feeds to do conveniently do that) Build contains build files, boot contains the files to be booted from grub. It's impossible to guess what could have gone wrong without knowing your configuration. Can you post the top level config.out? -Jan -- Jan Stoess System Architecture Group University of Karlsruhe Phone: +49 (721) 608-4056 Fax: +49 (721) 608-7664 eMail: stoess< at >ira.uka.de

Re: Fpage mapping in L4 Pistachio

Katsumi Maruyama — 2008-04-14T09:00:40

Dear Espen Skoglund: Than you for your help. I tried some KDB commands. (I am not familiar wth the KDB. A KDB manual is wanted.) ------ Test condition ---- The test condition is as follows: [1] Mapper mapper This means: Buffer ia located at [a26820-a28000]. (size is 6113) Mapper Flexpage : (a26820 is very delicated address !?) [2] Mappee (My mappee assigns the idle mappee fpage at 1G + 1M*n of 1M window size ) mappee<40606820-40608000, 40600000, 1000000> Buffer is to be accessible at: [40606820-40608000] (6113 bytes) Mappee flex page: <40600000, 1000000> ========== KDB results ============= Followings are KDB results, just after receiveing mapping IPC in mappee. ------- d command -------- d >memdump 40606820 ######## ######## ######## ######## ..... ===> Expecting pages seem not mapped. ---- p command ------------ > ptab ....... 40400000 [0b44a027]: tree=fb44a000 40500000 ............. 40501000 ............ 40600000 [0117a0

Re: Fpage mapping in L4 Pistachio

Espen Skoglund — 2008-04-11T10:34:40

[Katsumi Maruyama] Try dumping the page table of the mapper ('p' in kdb). Also, try dumping the mapping database for the page frame in question ('m' in kdb I think, and provide the physical address of the page). eSk

Re: Fpage mapping in L4 Pistachio

Katsumi Maruyama — 2008-04-11T05:35:06

Dear Espen Skoglund,: Thank you for your help. I added some KDB result. Yes, it can be accessed at 0x40000820. I meant: strncpy(0x40000820, mappeeOwnBuffer, SIZE); i.e. mappee --> mapper Right after receiving the mapping-IPC, I confirmed the mappint using KDB d command. d 40000820 >memdump Dump address [0x0]: 0x40000820 40000820 00000000 00000000 00000000 00000000 ....... .... (3-2) WHEN XSIZE > 6112: COPY FAILED I expected the mapping at 0x40006820, but it seemed not-mapped. KDB d command answered: d 0x40006820 Dump address [0x0]: 0x40006820 0x40006820 ######## ######## ######## ######## ..... Before the mapping IPC call, mapper filled the buffer with 0, thus pages are present. Umm. my test code seems not conflicting with the limitation. --- K. Maruyama, L4-devotee NII, Japan

Query

Anand Gore — 2008-04-11T05:00:48

Hi, I posted this question already on one of the L4 mailing list, I am not very sure which is right place for this question. So I am posting it here to, sorry for the spam. I wanted to dynamically load a binary to a specific location e.g. 0x2000000 in my task/thread. Here is the code I have - mnsigned int base_address=0x200000; mm_s memsection_create_fixed(section_size, base_address); if(mm_s != 0) { memcpy(base_address, binary_buffer, sizeof(binary_buffer)); func=(func_t)base_address; func(); } The binary is built and linked to a fixed address 0x2000000, such that there will be an initialization function at 0x2000000. But I read in the document that the memsection_create_fixed is going to go away sometime down the line. I am wondering if there is going to be a replacement function for that or there is a better way to do this. Thank you. Anand (858)-812-0637 Novatel Wireless, Inc. This email and any attachments may contain confidential and privileged information. If you are not th

Re: Fpage mapping in L4 Pistachio

Espen Skoglund — 2008-04-10T10:48:14

[Katsumi Maruyama] And the xbuf[] array is accessible at address 0x40000820 of mappee. BTW, saying "copied" here can be confusing. Copying and mapping are not the same thing. And the xbuf[] array should now be accessible at address 0x40006820 of mappee. Is this not happening? I don't know if you misunderstood it because I don't know what you expect to happen. The limitation of mapping is that pages not present in the mapper will (obviously) not be mapped to the mappee. Also, mapper can not map its own KIP or UTCB memory, and mappee can not receive mappings in its own KIP and UTCB memory. eSk

Afterburner-Wedge Compile Error - Need Help!

muhammad saufy — 2008-04-10T08:19:01

Hi All l4ka mailing list members, i had read most of the post here and i have other problem than what discuss here so far. ( i hope) i compiling afterburner with pistachio in 2 machine. (one my notebook with Intel VT and my desktop with Intel Pentium 4 (without VT). On my laptop, the error is: ========================== before that i configure the kernel to do: -compile on pentium 3 (i dont know why people say with core 2 due, need to use pentium 3) -l4ka with VMX (hardware virtualization) -use custom version of pistachio (debug) -build l4ka wedges -with guest kernel linux 2.6 -with vga boot option -when i enable the options of wedge-use-real device this error occur ===> common/crtend.cc ===> l4ka-resourcemon Configuring the Afterburn wedge-l4ka-passthru-p3 #< at >echo "Options WEDGE_L4KA DEVICE_PASSTHRU DEVICE_APIC=n ARCH_IA32=y L4KA_VT=y L4KA_INTERFACE_DIR=/root/afterburner/.//l4ka-interfaces L4KA_PISTACHIO_USER=/root/afterburner/usr DEVICE_PCI_FORWARD=n CPU_P3" make[1]: Entering directory `/root/aft

Fpage mapping in L4 Pistachio

Katsumi Maruyama — 2008-04-10T04:31:28

Ｄｅａｒ　ｓｉｒ： For inter-process data copying, I am using Flex page mapping conveniently. However, I noticed copy failure when the Fpage is large. My program outline is as follows: (Code is only explanatory, not real one) Let me call the mapping side process as Mapper, and mapped side process as Mappee. ==== (1) Mappee ================== (1-1) Receive window Fpage: mappeefpage: L4_Fpage(0x40000000, 0x100000) i.e. 1 mega bytes recv window from 1 Giga ==== (2) Mapper =================== (2-1) Buffer to send/receive data char xbuf[XSIZE]; // This buffer happened being allocated at 0xA26820. The Flex page which cover this buffer is used for mapping. strncpy() is used for string copying. ====== (3) Situation ======== (3-1) WHEN XSIZE <= 6112: No problem Fpage of Mapper: mapperfpage: L4_Fpage(0xA26000, 0x2000) with R/W permissions MapItem: mapitem: L4_MapItem(mapperfpage, 0) i.e. send-base is 0. Fpage is mapped, and data is rightly copyed from Mappee to Mapper. (3-2) WHEN XSIZE > 6112

Cannot start roottask

Julian Pidancet — 2008-04-10T00:35:56

Hi. I can't have roottask running with L4Ka::pistachio. I've tried to run the pingpong test program and also a handly-written simple helloworld program. I've tried on both Qemu and real netbooting machine. I've also tried several kernel configuration, without any results. With qemu and a gdb stub, the entry point of the roottask is never reached (whereas sigma0 seems to start). Here is a sample kernel config I've tried : # # Automatically generated, don't edit # # Generated on: soma # At: Sun, 06 Apr 2008 23:14:32 +0000 # Linux version 2.6.24-ARCH (root< at >T-POWA-LX) (gcc version 4.3.0 (GCC) ) #1 SMP PREEMPT Mon Mar 24 11:54:58 UTC 2008 # # Pistachio Kernel Configuration System # # # Hardware # # # Basic Architecture # CONFIG_ARCH_X86=y # CONFIG_ARCH_POWERPC is not set # CONFIG_ARCH_POWERPC64 is not set # # X86 Processor Architecture # CONFIG_SUBARCH_X32=y # CONFIG_SUBARCH_X64 is not set # # Processor Type # # CONFIG_CPU_X86_I486 is not set CONFIG_CPU_X86_I586=y # CONFIG_CPU_X86_I686 is not set # CO

RE: Pistachio debugger: stack backtrace

Jan Stoess — 2008-03-31T10:49:03

Hello Julian, There is no built-in support for generating stack backtraces in Pistachio, neither for user nor for kernel-stacks. Cheers, -Jan -- Jan Stoess System Architecture Group University of Karlsruhe Phone: +49 (721) 608-4056 Fax: +49 (721) 608-7664 eMail: stoess< at >ira.uka.de

Pistachio debugger: stack backtrace

Julian Stecklina — 2008-03-26T23:45:39

Hello, is there a way to generate a stack backtrace using the Pistachio kernel debugger? Regards,

RE: problem about writing a hello world for VM

Jan Stoess — 2008-03-11T07:43:14

The boot process follows a cooperative scheme where the next VM is started in IResourcemon_client_init_complete_implementation(), which is a callback function invoked by the current wedge via IDL. code which can run as a VM? You could look at some toy OSes built upon L4 for that purpose: e.g., http://l4ka.org/relatedprojects.php lists a couple of such OSes developed by students during course projects here at the chair. -Jan -- Jan Stoess System Architecture Group University of Karlsruhe Phone: +49 (721) 608-4056 Fax: +49 (721) 608-7664 eMail: stoess< at >ira.uka.de