l4-hackers

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

2827 discussions

clarification on explicit preemption points in Fiasco IPC
by Sergio Ruocco 26 Jun '07

26 Jun '07

Hi all, Forgive me if this is a silly question because it is documented somewhere, but I am unfamiliar with Fiasco source, and too in a hurry to go through all the Fiasco source code and cross-comare it with the documentation/papers/examples etc.... Skimming though Fiasco source code I checked out few weeks ago (the Doxygen online version is from 2005, out of date), I found 16 "Proc::preemption_point();" in the IPC path in the source file thread-ipc.cpp: [sergio 19:41 ~/Desktop/FIASCO/tudos/kernel/fiasco/src/kern]$ grep Proc::preemption_point thread-ipc.cpp | wc -l 16 Which tudos/kernel/fiasco/src/drivers/processor.cpp defines as: ... static inline void preemption_point() { sti(); irq_chance(); [ NOP NOP ] cli(); } ... My question is: As far as I know, Fiasco is entirely preemptable. Then why sprinkling the IPC path with Enable IRQs/NOP NOP/Disable IRQs ? Is there a document or a paper that discuss which parts of the kernel run with IRQs disabled / enabled ? Preemption disabled / enabled etc. ? Thanks in advance, Sergio -- Sergio Ruocco, PhD Research Fellow ruocco(a)disco.unimib.it / sergio.ruocco(a)gmail.com NOMADIS Lab. phone: +39-02-6448-7879 mobile, embedded real-time systems skype: 'sergioruocco' Università degli Studi di Milano-Bicocca, Italy

3 3

Re: 16-bit code and L4
by Valery V. Sedletski 25 Jun '07

25 Jun '07

On Mon, 25 Jun 2007 18:43:55 +1300 (MSD), Valery V. Sedletski wrote: >Yes, I see: > >L4_INLINE void >fiasco_gdt_set(void *desc, unsigned int size, > unsigned int entry_number_start, l4_threadid_t tid); > >It is privileged architecture-specific syscall, as I understood. And what means >"sanity checking" by the kernel? Does the kernel simply check that the descriptor >defines a valid segment, or, there are some additional chacks. For example, must >segments to be a non-overlapping, or not? (For 32-bit<-->16-bit thunking it is important >to have a possibility for the segments to be overlapping -- the code can be at the same >time to be in 16-bit segment and 32-bit segment). In segment.h header, there is an implementation of this function, through using LLDT instruction. (and not through using a special syscall). So, LLDT instruction is allowed for usermode programs, and the kernel intercept lldt instruction. -- Probably when this instruction is used in usermode program, the TRAP occurs, and the kernel handles this trap, modifying the LDT or GDT. Is this right? (I searched an fiasco_gdt_set() function in the source code and I found that L4Linux uses this function. So, it is, probably, was created for demands of L4Linux development?)

2 1

Re: 16-bit code and L4
by Valery V. Sedletski 25 Jun '07

25 Jun '07

> >I was working on allowing applications to use segmentation in >Pistachio as well. The modifications enabled apps to install segment >descriptors in a per address space LDT (after sanity checking by the >kernel of course). Modifying the GDT is not supported. > Is GDT modifying support planned in the future? > >By setting a thread in a special mode the kernel will never modify the >ES, FS, and GS of the thread. For optimization reasons the kernel >still retains the right to modify DS and SS though, so in effect these >can not be freely used by the app. Also, the kernel only allows data >segments to be installed --- no code or other segment types. > >It's been a while since I worked on this and got sidetracked by other >stuff, so I didn't completely finish the implementation yet. > > eSk > Is this documented somewhere? (It seems that it is not documented in L4 version X.2 API manual.) Maybe, it is in some source code documentation (Doxygen generated or alike)? > > > Thank you very much for your answer. WBR, Valery

1 0

Re: 16-bit code and L4
by Valery V. Sedletski 25 Jun '07

25 Jun '07

Thanks for answening so quickly. >> >Fiasco makes some GDT slots available to userland so that FS and GS can >> >be used with those. >> > >> >> And how to access these GDT descriptors from userland? Is this >> documented somewhere? Can usermode task change attributes of these >> descriptors (such as "16-bits" attribute)? Are they (descriptors) >> somehow mapped to requestor's address space or how else can usermode >> task modify these descriptors? Or, can usermode task only load >> selectors corresponding to these descriptors, but not modify >> descriptors itself? > >Userland can load descriptors that are sanity checked by the kernel and >then stored in the GDT. Using 16-bit segments should work too although I >never tried. Similar features are offered for the LDT. Our l4sys package >contains segment.h headers which describe the kernel interface. > Yes, I see: L4_INLINE void fiasco_gdt_set(void *desc, unsigned int size, unsigned int entry_number_start, l4_threadid_t tid); It is privileged architecture-specific syscall, as I understood. And what means "sanity checking" by the kernel? Does the kernel simply check that the descriptor defines a valid segment, or, there are some additional chacks. For example, must segments to be a non-overlapping, or not? (For 32-bit<-->16-bit thunking it is important to have a possibility for the segments to be overlapping -- the code can be at the same time to be in 16-bit segment and 32-bit segment). ... > >> And what about DS/ES? Can usermode task load these registers with >> another selector, as with FS/GS? > >Loading should work I guess but DS and ES are currently not restored on >exit to user. > so, if user restores these segments on exit, the loading should work? > > >Adam >-- >Adam adam(a)os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ > > >

1 0

Playing with ORe
by Marc CHALAND 22 Jun '07

22 Jun '07

Hi everybody, I did some experiments with ORe. I played with arping and I modified it to reply to ICMP from windows. I also added one option to ORe to prevent promiscuous mode when not necessary. cf attachment Best Regards

2 1

Thesis on verification of Fiasco's IPC implementation
by Erik Schierboom 22 Jun '07

22 Jun '07

Hi all, As some of you will probably already know, I have been working on the verification of (a part of) Fiasco's IPC implementation. This week I have finished my thesis and the result can be found at the following location: http://www.swyp.nl/thesis.pdf Thanks for all the help I have received. With regards, Erik Schierboom

1 0

Re: 16-bit code and L4
by Valery V. Sedletski 22 Jun '07

22 Jun '07

>On Thu Jun 21, 2007 at 03:55:24 +1300, Valery V. Sedletski wrote: >> >>> 2) Must all the segment registers be CS == DS == ES == FS == GS == SS == FLAT in L4 usermode >> >programs (in Intel >> >>> architecture implementation)? Or, there exist a possibility to use segments other than FLAT? >> >>> >> >>Fiasco preserves some of these segments (e.g., GS to support thread >> >>local storage). However, unless OS/2 makes use of these segments in >> >>32-bit mode there is no need to change these from a flat setting. >> > >> >It seems, that OS/2 does not use GS (GS seems to be always == 0), at least, in application programs. >> > >> >> But also FS is used to address a structure named Thread Info Block >> (TIB), it is also not flat (it has a limit=0x30) So, FS is used by >> OS/2 and programs depend on it. GS seems to be not used, and ES and DS >> are generally flat. > >Fiasco makes some GDT slots available to userland so that FS and GS can >be used with those. > And how to access these GDT descriptors from userland? Is this documented somewhere? Can usermode task change attributes of these descriptors (such as "16-bits" attribute)? Are they (descriptors) somehow mapped to requestor's address space or how else can usermode task modify these descriptors? Or, can usermode task only load selectors corresponding to these descriptors, but not modify descriptors itself? So it is with Fiasco, and what about Pistachio? (Is this mailing list the right place to ask such questions, or it is better to ask them at l4ka(a)ira.uka.de?) And what about DS/ES? Can usermode task load these registers with another selector, as with FS/GS? > > >Adam >-- >Adam adam(a)os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ >

3 2

Re: 16-bit code and L4
by Valery V. Sedletski 20 Jun '07

20 Jun '07

>>> 2) Must all the segment registers be CS == DS == ES == FS == GS == SS == FLAT in L4 usermode >programs (in Intel >>> architecture implementation)? Or, there exist a possibility to use segments other than FLAT? >>> >>Fiasco preserves some of these segments (e.g., GS to support thread >>local storage). However, unless OS/2 makes use of these segments in >>32-bit mode there is no need to change these from a flat setting. > >It seems, that OS/2 does not use GS (GS seems to be always == 0), at least, in application programs. > But also FS is used to address a structure named Thread Info Block (TIB), it is also not flat (it has a limit=0x30) So, FS is used by OS/2 and programs depend on it. GS seems to be not used, and ES and DS are generally flat.

2 1

16-bit code and L4
by Valery V. Sedletski 20 Jun '07

20 Jun '07

Would be someone so kind to answer some questions? These questions are about 16-bit instructions execution on intel processors in L4 usermode programs. First, excuse me for my bad English (it is not native for me). And first I'll try to explain the motivation. -- I am now trying to contribute to the project aiming to create an Opensource OS/2 clone. (osFree aka OS/3 project, http://www.osfree.org/) The goal now is to create OS/2 API implementation with binary compatibility with existing OS/2 (intel) applications. Also, it would be desirable to reuse existing OS/2 device driver base (if it is possible). We are planning to use L4 as a base for API implementation. The problem with existing OS/2 applications is that they are not pure 32-bit; there are many common 16-bit API's now (they are to be replaced with 32-bit analogues in new implementation); almost each LX format executable contains 16-bit fragments (thunks for calling 16-bit API's), though the most of each executable is 32-bit and uses 32-bit flat memory model. Also, most old OS/2 device drivers are 16-bit, they are still very common now (but newer drivers are 32-bit). Another problem is that many drivers and applications are available in binary-only form (so, they cannot be recompiled, as with Linux) 32-bit applications and drivers support can be made, for example, by implementing a converter of LX-executables to pure 32-bits. Also, 16-bit fragments can be executed in a virtual machine. Or, as another variant, it may be possible to execute these 16-bit parts on a real processor. The problem is only how to maintain correct segment registers values and how to add a 16-bit segment descriptor to GDT or LDT. The problem with L4 is that it doesn't expose segmentation to outside the kernel, it abstracts segmentation from usermode programs and only allows to use paging, but not segmentation. The reason is known: segmentation is not portable, it has no analogues on other architectures than intel one. So, the questions are: 1) There is L4Linux. It is mostly 32-bit. But as I know, the Linux kernel also contains some 16-bit parts, such as setup code (it works with BIOS routines and probes hardware), and also (as I heard) acpi suspend/wakeup code. So, it contains 16-bit segments. But doesn't it interfere with L4? How did the people porting Linux to the L4 microkernel solve the problem of 16-bit code? And doesn't it interfere with ELF format capabilities (it is pure 32/64-bit, as I understand)? 2) Must all the segment registers be CS == DS == ES == FS == GS == SS == FLAT in L4 usermode programs (in Intel architecture implementation)? Or, there exist a possibility to use segments other than FLAT? 3) Is it possible to cause the L4 kernel to create 16-bit segment descriptor on Intel architecture?

2 2

Re: Fiasco@ARM - supported hardware
by Daniel Vandersee 19 Jun '07

19 Jun '07

Hi Jorge, I just tried it and it doesn't work for me, too. If I break the program execution after a while it always stops at uart_write+72: > 0xb0002e30 <uart_write+64>: ldr r3, [r2, #32] > 0xb0002e34 <uart_write+68>: tst r3, #4 ; 0x4 > 0xb0002e38 <uart_write+72>: beq 0xb0002e30 <uart_write+64> > 0xb0002e3c <uart_write+76>: ldrb r3, [r0, r12] Did you got it running with skyeye? Attached you will find my skyeye configuration. Maybe you have an idea what goes wrong here? Thanks! Cheers, Daniel Jorge Torres schrieb: > Hi Daniel, > > Have you tried PXA borad with skyeye? > > Thanks, > > JOrge > > On 6/18/07, *Daniel Vandersee* < dvandersee(a)escrypt.com > <mailto:dvandersee@escrypt.com>> wrote: > > Hello, > > how do you test L4 on an ARM platform? Do you have specific hardware > for > that purpose? You mentioned that you use ARM Integrator boards. As there > are several integrator boards available: which one exactly do you use? > Do you use other boards as well? I'm asking because I plan to buy an > ARM > board which is supported out of the box without the need to modify > drivers. > > Do you additionally use software simulators to test L4? If so, which one > do you use? I tried Skyeye to simulate an ARM integrator board as well > as a SA1100-board but didn't get any output over the serial line. Qemu > doesn't work either and terminates with the following error: "qemu: > uncaught target signal 11 (Segmentation fault) - exiting". > > Kind regards, > Daniel > > > > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de <mailto:l4-hackers@os.inf.tu-dresden.de> > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers > > cpu: xscale #cpu: pxa25x mach: pxa_lubbock #cpu: pxa27x #mach: pxa_mainstone mem_bank: map=I, type=RW, addr=0x40000000, size=0x0c000000 mem_bank: map=M, type=RW, addr=0xb0000000, size=0x10000000 #mem_bank: map=M, type=RW, addr=0xd0000000, size=0x00100000 #log: logon=1, logfile=/tmp/sk2.log, start=500000, end=1500000 #lcd:state=on,type=pxa,mod=gtk uart: mod=stdio

1 0

Jump to page:

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