l4-hackers October 2000

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

8 participants
14 discussions

Re: Real-time Fiasco
by Michael Hohmuth 17 Oct '00

17 Oct '00

"kargahi"<kargahi(a)moe.or.ir> writes: > Would you please say me why Fiasco is a real-time u-kernel & what > are the real-time properties of Fiasco? For Fiasco, "Real-Time" means that Fiasco implements static ``hard'' thread priorities, and the worst-case time to react to an event such as an interrupt or a timeout are bound. To keep the bound low, Fiasco is is fully preemtible in kernel mode, and it guarantees that ``independent thread groups'' are always executable no matter what is going on in the kernel. > After that, please say me how the priorities affect the timeslice of a task > and where the timeslice of a task is allocated to it. The scheduler uses two variables: Priorities determine the order in which threads are executed (thread_t::schedule()). The time-slice length determines when the kernel considers running a different thread of the same priority. The kernel has the concept of a "current time slice" which is the number of clock ticks the current thread can execute without being preempted. The current time slice (timeslice_ticks_left) is checked in thread_timer_interrupt(), and it is initialized in thread_t::schedule(). Please not that it is not set on every kernel-context switch -- only when a thread is preempted or voluntarily goes to sleep (that is, only in thread_t::schedule(), not in thread_t::switch_to()). Different L4 kernels handle scheduling differently. Jean Wolter has a short paper describing the current state of the art for some L4 implementations that I'm sure he will make available for the asking. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: L4ka and Bochs (was: L4ka and plex86?)
by Farid Hajji 16 Oct '00

16 Oct '00

Hi Volkmar and Kevin, trying to get l4ka running under bochs would probably require slight modifications to the bochs sources, so that 4 MB pages (bit 4 PSE of CR4) can be supported (please see summary below). > ------------------ BoSnip ------------------- > > // Only allow writes of 0 to CR4 for now. > > // Writes to bits in CR4 should not be 1s as CPUID > > // returns not-supported for all of these features. > ------------------ EoSnip ------------------- > > So what happens is that we initialize 4MB pages (located in the first level > page dirs). > If bochs does not support 4MB pages - you are pretty much out of luck - we > currently do not support > 4K pages only. The kernels virtual view of physical memory is mapped as 4MB > pages. Furthermore, > RMGR and L4Linux assumes 4MB/Super-pages. So if you have absolutely no > possibility to get a normal > Pentium System - we have to do some mid-major :) changes of the startup > code. I don't hope that it would be necessary to tweak the l4ka sources so much (at least not for that 4MB problem). Looking at the sources of bochs, I think that it would be _much_ easier to add support for the PSE bit (bit 4 of CR4) to bochs itself at two places, rather than modifying l4ka. This is what I've found out so far (sorry for lengthy message): ---------- cut here ----------- cut here ------------- cut here -------------- Summary: ======== 1. About superpages, PSE bit etc... - - - - - - - - - - - - - - - - - - Intel Architecture Software Developer's Manual Volume 3: System Programming Order-Nr: 243192 http://developer.intel.com/design/pentiumii/manuals/24319202.pdf Section 3.6 Paging (Virtual Memory): PG-Flag (Bit 31 of CR0) enables paging translation, >= 386 PSE-Flag (Bit 4 of CR4) 4k or 4MB pages, >= 586 PAE-Flag (Bit 5 of CR4) 36Bit physical addr, >= 686 Section 3.6.2.1 Linear Address Translation (4 kByte Pages) Section 3.6.2.2 Linear Address Translation (4 MByte Pages) Section 3.6.2.3 Mixing 4kByte and 4MByte pages Section 3.8.2 Linear Address Translation With Extended Adressing Enabled (2 MByte or 4 MByte Pages). ====> PSE bit is only used while translating linear addresses to physical ====> addresses. paging directory entries and page table entries have slighly ====> different format (?) when 4 MB pages are involved. See figures ====> 3-14, 3-15, 3-18, 3-19, 3-20, 3-21. ====> In bochs, this is mainly located in the file: ====> bochs-2000_0325a/cpu/paging.cc 2. L4ka sources - - - - - - - - 2.1: l4-ka/kernel/src/x86/init.c:init_paging() .............................................. #if defined(CONFIG_ARCH_X86_I586) || defined(CONFIG_ARCH_X86_I686) /* Turn on super pages. */ enable_super_pages(); #endif ====> I configured with CONFIG_ARCH_X86_I586 to avoid having to: ====> #if defined(CONFIG_ARCH_X86_I686) ====> enable_global_pages(); ====> setup_sysenter_msrs(); ====> #endif 2.2: l4-ka/kernel/include/x86/cpu.h:enable_super_pages() ........................................................ INLINE void enable_super_pages() { __asm__ __volatile__ ("mov %%cr4, %%eax\n" "orl $0x10, %%eax\n" "mov %%eax, %%cr4\n" : : : "eax"); } ====> Turning on bit 4 of CR4 (PSE) enables 4 MB pages. ====> Volkmar: In Section 3.6.2.2 (at the End), the note says ====> Volkmar: that the TLBs _must_ be flushed (invalidated) after setting ====> Volkmar: or clearing the PSE bit. Forgot to do it? ====> This is the instruction that crashes bochs. 3. Bochs sources: - - - - - - - - - 3.1 output of bochs.out logfile: ................................ WBINVD: (ignoring) MOV_RdCd: read of CR4 MOV_CdRd: ignoring write to CR4 of 0x00000010 bochs: panic, MOV_CdRd: (CR4) write of 0x00000010 >> mov CR4, EAX ====> Bochs panic()s because it doesn't support CR4 bits yet (see below). ====> l4ka (enable_super_pages()) tries to set the PSE bit in CR4 because ====> it needs 4 MB superpages. 3.2 bochs-2000_0325a/cpu/proc_ctrl.cc: ...................................... This file contains the implementation of the x86-instructions. Let's look at the missing/buggy parts that were reported in bochs.out above: 3.2.1: WBINVD: (ignoring): . . . . . . . . . . . . . void BX_CPU_C::WBINVD(BxInstruction_t *i) { bx_printf("WBINVD: (ignoring)\n"); #if BX_CPU_LEVEL >= 4 invalidate_prefetch_q(); if (BX_CPU_THIS_PTR cr0.pe) { if (CPL!=0) { bx_printf("WBINVD: CPL!=0\n"); exception(BX_GP_EXCEPTION, 0, 0); } } BX_INSTR_CACHE_CNTRL(BX_INSTR_WBINVD); #else UndefinedOpcode(i); #endif } ====> BX_CPU_LEVEL was defined to be 5, so invalidate_prefetch_q() ====> was called. WBINVD (invalidates TLB etc...) seems to be okay. 3.2.2: read of CR4: . . . . . . . . . . void BX_CPU_C::MOV_RdCd(BxInstruction_t *i) { // mov control register data to register <snip> case 4: // CR4 #if BX_CPU_LEVEL == 3 val_32 = 0; bx_printf("MOV_RdCd: read of CR4 causes #UD\n"); UndefinedOpcode(i); #else bx_printf("MOV_RdCd: read of CR4\n"); val_32 = BX_CPU_THIS_PTR cr4; #endif break; <snip> } ====> This seems to be okay once more. The contents of the variable ====> cr4 can be read on this BX_CPU_LEVEL of 5. 3.2.3: ignoring write to CR4 of 0x00000010....., then panic() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . void BX_CPU_C::MOV_CdRd(BxInstruction_t *i) { // mov general register data to control register <snip> case 4: // CR4 #if BX_CPU_LEVEL == 3 bx_panic("MOV_CdRd: write to CR4 of 0x%08x on 386\n", val_32); UndefinedOpcode(i); #else // Protected mode: #GP(0) if attempt to write a 1 to // any reserved bit of CR4 bx_printf("MOV_CdRd: ignoring write to CR4 of 0x%08x\n", val_32); if (val_32) { bx_panic("MOV_CdRd: (CR4) write of 0x%08x\n", val_32); } // Only allow writes of 0 to CR4 for now. // Writes to bits in CR4 should not be 1s as CPUID // returns not-supported for all of these features. BX_CPU_THIS_PTR cr4 = 0; #endif break; <snip> } ====> This has to be tweaked, perhaps by adding a call to a new ====> CR4_change() function (like CR3_change()), which can ====> then be added to paging.cc. If the change is minimal, ====> modifying variable cr4 directly may be enough. Anyway, ====> in paging.cc, the translation functions must take into ====> account the PSE bit it cr4!!! 3.3 bochs-2000_0325a/cpu/paging.cc .................................. // Translate a linear address to a physical address, for // a data access (D) Bit32u BX_CPU_C::dtranslate_linear(Bit32u laddress, unsigned pl, unsigned rw) { <snip long code which uses cr0, cr3 but not cr4 (yet)> } // Translate a linear address to a physical address, for // an instruction fetch access (I) Bit32u BX_CPU_C::itranslate_linear(Bit32u laddress, unsigned pl) { <snip long code which uses cr0, cr3 but not cr4 (yet)> } ====> these functions will have to additionally take into ====> account the value in cr4 (e.g. PSE bit), so that ====> 4 MB pages are supported. ---------- cut here ----------- cut here ------------- cut here -------------- Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

3 2

Trying L4ka under Bochs/FreeBSD (the saga continues...).
by Farid Hajji 15 Oct '00

15 Oct '00

Hi, [Kevin: please have a look at the bochs panic below: What's wrong with writing non-zero to CR4 when --enable-cpu-level=5 is mentioned? Is there a quick workaround to this problem? Thanks.] I'm trying to run l4ka under bochs but I'm still fighting with some bochs panic()s. This is what I've found out so far: 1. 3 modules _must_ be attached to rmgr, so that the assertion in startup() about the number of modules doesn't bite. 2. I used the following grub startup commands thru all following tests (bochs simulates disk C: from a 112M bytes regular file): grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> kernel (hd0,0)/l4ka/rmgr.debug -sigma0 [Multiboot-elf, <0x111000:0x20734:0x0>, <0x132740:0x48c:0xfcc8>, entry=0x111000] grub> module (hd0,0)/l4ka/x86-kernel [Multiboot-module @ 0x143000, 0x12769 bytes] grub> module (hd0,0)/l4ka/sigma0 [Multiboot-module @ 0x156000, 0x287a bytes] grub> module (hd0,0)/l4ka/glinux [Multiboot-module @ 0x159000, 0x143dd4 bytes] grub> boot rmgr.debug is just original rmgr binary, with another name. I tried to slightly modify rmgr in later steps... rmgr[.debug], x86-kernel and sigma0 were compiled on FreeBSD without problems. Note: compiled for 586, not 686!. They are not stripped. I was not able to compile linux22 from Dresden on FreeBSD, so I just used the binary 'glinux' from your distribution. 3. Without any modifications to the l4-ka sources, bochs panic()s right after displaying the message: check_l4_version 0x00100000 to 0x0011041c with the following error message: MOV_RdCd: read of CR4 MOV_CdRd: ignoring write to CR4 of 0x00000010 bochs: panic, MOV_CdRd: (CR4) write of 0x00000010 protected mode CS.d_b = 32 bit SS.d_b = 32 bit | EAX=00000010 EBX=ff000000 ECX=0010f40f EDX=0010a000 | ESP=0010f3f7 EBP=00109000 ESI=f0109000 EDI=00109000 | IOPL=0 NV UP DI PL NZ NA PO NC | SEG selector base limit G D | SEG sltr(index|ti|rpl) base limit G D | DS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | ES:0010( 0002| 0| 0) 00000000 000fffff 1 1 | FS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | GS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | SS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1 | EIP=0010fa55 (0010fa52) >> 77875018 0f77875018 2277875018 e077875018 : mov CR4, EAX bochs was not able to grok the instruction: mov CR4, EAX (that is EAX -> CR4). I compiled bochs-2000_0325a with the following options: ./configure --enable-cpu-level=5 \ --enable-disasm --enable-vga --enable-fpu \ --enable-x86-debugger Support for x86-debugger (DR? registers etc...) is therefore enabled. Looking at the source code of bochs-2000_0325a, file cpu/proc_ctrl.cc says in function void BX_CPU_C::MOV_CdRd(BxInstruction_t *i): [...] case 4: // CR4 #if BX_CPU_LEVEL == 3 bx_panic("MOV_CdRd: write to CR4 of 0x%08x on 386\n", val_32); UndefinedOpcode(i); #else // Protected mode: #GP(0) if attempt to write a 1 to // any reserved bit of CR4 bx_printf("MOV_CdRd: ignoring write to CR4 of 0x%08x\n", val_32); if (val_32) { bx_panic("MOV_CdRd: (CR4) write of 0x%08x\n", val_32); } // Only allow writes of 0 to CR4 for now. // Writes to bits in CR4 should not be 1s as CPUID // returns not-supported for all of these features. BX_CPU_THIS_PTR cr4 = 0; #endif break; [...] So bochs doesn't allow writing 0x00000010 (non-zero) to CR4 for now. To Kevin: Why? To Uwe: Can we avoid having to write to CR4 for now? 4. I tried to localize the exact position of that instruction in l4-ka by adding the following MYDEBUG macro to halt execution before bochs panic()s: #ifndef MYDEBUG #define MYDEBUG(str) { printf(str); for(;;) ; } #endif this helped to track down at least portions of the code that were definitely executed by bochs, as well as to see the output. This is what I've found out so far: 4.1. control definitely reaches the end of l4-ka/apps/rmgr/src/startup.c:startup(), at least just before the final: asm volatile ("pushl $" SYMBOL_NAME_STR(exit)"\n" "pushl %2\n" "ret\n" : /* no output */ : "a" (MULTIBOOT_VALID), "b" (&l4_mbi), "r" (exec_info.entry)); /*NORETURN*/ This is the output in bochs: RMGR: loading (hd0,0)/l4ka/sigma0 check_l4_version 0x00100000 to 0x0011041c RMGR: detected L4-Karlsruhe find kernel info page... found kernel info page at 0x00107000 configuring s0: (0x00200000, 0x00213000), start: 0x00200000 s0 config: 0x00200000,0x00000000,0x00200000,0x00213000 RMGR: reserve modules memory range: 156000 to 29cdd4 RMGR: starting (hd0,0)/l4ka/x86-kernel @ 0x0010f000 >>>> rmgr.debug:startup() just before asm volatile... at end of function. 4.2. control doesn't reach even the very beginning of l4-ka/apps/rmgr/src/init.c:init() where I've put the next MYDEBUG call. bochs panic()s with the same error message as before (ignoring write to CR4 of 0x00000010: mov CR4, EAX). Uwe, where does startup() exactly jumps to? I thought it was rmgr's init()??? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0

Real-time Fiasco
by kargahi 11 Oct '00

11 Oct '00

Hi L4 Hackers Would you please say me why Fiasco is a real-time u-kernel & what are the real-time properties of Fiasco? After that, please say me how the priorities affect the timeslice of a task and where the timeslice of a task is allocated to it. Thanks.

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 October 2000