Subversion Repositories HelenOS

Compare Revisions

Ignore whitespace Rev 533 → Rev 534

//kernel/trunk/doc/arch/ia32
0,0 → 1,35
ia32 port
=========
 
ia32 port is the oldest and the most advanced one.
It was originally written by Jakub Jermar.
It is meant to support ordinary PC's based on IA-32 architecture.
Both uniprocessor and multiprocessor modes are supported.
It runs both in emulated environment and on real hardware.
 
HARDWARE REQUIREMENTS
o IA-32 processor (Pentium and successors)
 
COMPILER REQUIREMENTS
o binutils 2.15 and gcc 3.3.5
o binutils 2.16 and gcc 4.0.1
o older versions may do as well, but are now obsoleted
 
SMP COMPATIBILITY
o Bochs 2.0.2 - Bochs 2.2.1
o 2x-8x 686 CPU
o Simics 2.0.28 - Simics 2.2.19
o 2x-15x Pentium 4 CPU
o VMware Workstation 5.5
o 2x CPU
o ASUS P/I-P65UP5 + ASUS C-P55T2D REV. 1.41
o 2x 200Mhz Pentium CPU
o ASUS PCH-DL
o 2x 3000Mhz Pentium 4 Xeon (HT) CPU
o MSI K7D Master-L
o 2x 2100MHz Athlon MP CPU
 
EMULATORS AND VIRTUALIZERS
o Bochs 2.0.2 - Bochs 2.2.1
o VMware Workstation 4, VMware Workstation 5, VMware Workstation 5.5
o Simics 2.2.19
//kernel/trunk/doc/arch/mips32
0,0 → 1,23
mips32 port
===========
 
mips32 is the second port of SPARTAN kernel originally written by Jakub Jermar.
It was first developed to run on MIPS R4000 32-bit simulator.
Now it can run on real hardware as well.
It can be compiled and run either as little- or big-endian.
 
HARDWARE REQUIREMENTS
o SGI Indy R4600
o emulated MIPS 4K CPU
 
CPU
o QED R4600
 
COMPILER REQUIREMENTS
o mips binutils 2.16 and gcc 4.0.1 cross compiler
o older versions may do as well, but are now obsoleted
 
EMULATORS AND VIRTUALIZERS
o msim 1.2.8
o gxemul - both big and little endian
o simics 2.2.19
//kernel/trunk/doc/arch/sparc64
0,0 → 1,8
sparc64 port
============
 
Currently, this porting effort is subject to
Jakub Jermar's work on his master thesis.
 
The goal is to provide support for UltraSPARC
implementation of SPARC V9 architecture.
//kernel/trunk/doc/arch/amd64
0,0 → 1,26
amd64 port
==========
 
The fifth port, amd64 port, was originally written by Ondrej Palkovsky.
The goal is to support AMD64 and Intel Extended Memory 64 Technology PC's.
The port makes use of portable parts of ia32.
Both uniprocessors and multiprocessors are supported.
The kernel runs on real hardware and in simulators too.
 
HARDWARE REQUIREMENTS
o AMD64 architecture processor
o Intel Extended Memory 64 Technology processor
 
CPU
o Intel Xeon with Intel Extended Memory 64 Technology
 
SMP COMPATIBILITY
o Bochs 2.2.1
o 2x-8x AMD64 CPU
o Simics 2.2.19
o 2x-8x AMD hammer CPU
o HP ProLiant ML350 (HyperThreading)
 
EMULATORS AND VIRTUALIZERS
o Bochs 2.2.1
o Simics 2.2.19
//kernel/trunk/doc/arch/ia64
0,0 → 1,15
ia64 port
=========
 
ia64 port is the third port of SPARTAN originally written by Jakub Jermar.
It is still in its early stages. It runs on HP Ski simulator of IA-64 architecture.
 
HARDWARE REQUIREMENTS
o no real hardware supported
 
EMULATORS AND VIRTUALIZERS
o ski
 
COMPILER REQUIREMENTS
o IA-64 binutils 2.15 and gcc 4.0.0 cross compiler
o older versions may do as well, but are now obsoleted
//kernel/trunk/doc/arch/ppc32
0,0 → 1,15
ppc32 port
==========
 
ppc32 port is the fourth port of SPARTAN, originally written by Martin Decky.
The goal is to support 32-bit PowerPC architecture.
So far, it runs only in emulator.
 
HARDWARE REQUIREMENTS
o no real hardware supported
 
EMULATORS AND VIRTUALIZERS
o PearPC
 
COMPILER REQUIREMENTS
o binutils 2.16 and gcc 4.0.1
//kernel/trunk/doc/BUGS_FOUND
0,0 → 1,22
During development of this operating system, there were found bugs in:
 
Simics
======
- ia32 BIOS rewrites memory during AP start in SMP environment (#3351)
- ia32 Simics does not report #GP when EFER.NXE is 0 and finds NX page (#4214)
- incorrect MIPS instructions MSUB, MSUBU
 
Bochs
=====
- FXSAVE/FXRSTOR not working correctly with XMM registers (patch #1282033)
 
Msim
====
- Incorrect interpretation of lwl/lwr/swl/swr instructions
- Omitted excMod case in write_proc_mem()
 
Gcc
===
- Incorrect generation of unaligned data access instructions
(lwl/lwr/swl/swr) when using mipsel- target and -EB(big endian)
compilation, -O2 (#23824)
//kernel/trunk/doc/TODO
0,0 → 1,27
+ implement true memory barriers for all architectures
 
+ implement true memory management
+ [ia32] use int 0x15 ax=0xe820 to get memory map and memory size [DONE]
+ [mips] use some heuristics to get memory map and memory size
+ reimplement heap so that it can allocate/deallocate
itself frames as necessary
+ provide native four-level portable page table interface [DONE]
+ every architecture uses its native page table format
+ kernel provides unified four-level page table interface
for all architectures
+ track usage of frames containing middle-level page tables
(frame leak)
 
+ get user mode support for all architectures
 
+ save/restore floating point context on context switch
+ [ia32] lazy context switch using TS flag [DONE]
+ [ia32] MMX,SSE1-.. initialization
+ [ia32] review privilege separation [DONE]
+ zero IOPL in EFLAGS [DONE]
+ before IRET (from SYSCALL), zero NT in EFLAGS [DONE]
+ [ia32] review the cache controling bits in CR0 register
+ [ia32] zero the alignment exception bit in EFLAGS [DONE]
- Task changed to clear AM in CR0 so that
the alignment check is disabled globally
+ make emulated architectures also work on real hardware
//kernel/trunk/doc/AUTHORS
0,0 → 1,6
Jakub Jermar <jermar@itbs.cz>
Jakub Vana <jakub.vana@gmail.com>
Martin Decky <martin@decky.cz>
Josef Cejka <malyzelenyhnus@seznam.cz>
Sergey Bondari <bondari@itbs.cz>
Ondrej Palkovsky <ondrap@penguin.cz>
//kernel/trunk/doc/mm
0,0 → 1,52
Memory management
=================
 
SPARTAN kernel deploys generic interface for 4-level page tables,
no matter what the real underlying hardware architecture is.
 
 
VADDR
+-----------------------------------------------------------------------------+
| PTL0_INDEX | PTL1_INDEX | PTL2_INDEX | PTL3_INDEX | OFFSET |
+-----------------------------------------------------------------------------+
 
 
PTL0 PTL1 PTL2 PTL3
+--------+ +--------+ +--------+ +--------+
| | | | | PTL3 | -----\ | |
| | | | +--------+ | | |
| | +--------+ | | | | |
| | | PTL2 | -----\ | | | | |
| | +--------+ | | | | | |
| | | | | | | | +--------+
+--------+ | | | | | | | FRAME |
| PTL1 | -----\ | | | | | | +--------+
+--------+ | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
+--------+ \----> +--------+ \----> +--------+ \----> +--------+
^
|
|
+--------+
| PTL0 |
+--------+
 
 
PTL0 Page Table Level 0 (Page Directory)
PTL1 Page Table Level 1
PTL2 Page Table Level 2
PTL3 Page Table Level 3
 
PTL0_INDEX Index into PTL0
PTL1_INDEX Index into PTL1
PTL2_INDEX Index into PTL2
PTL3_INDEX Index into PTL3
 
VADDR Virtual address for which mapping is looked up
FRAME Physical address of memory frame to which VADDR is mapped
 
 
On architectures whose hardware has fewer levels, PTL2 and, if need be, PTL1 are
left out. TLB-only architectures are to define custom format for software page
tables.
//kernel/trunk/doc/synchronization
0,0 → 1,29
 
SPINNING LOCKS
spinlock_lock, spinlock_trylock, spinlock_unlock
+------------+
| spinlock_t |
+------------+
 
WAIT QUEUES
waitq_sleep_timeout, waitq_wakeup
+---------+
| waitq_t |
+---------+
/ \
SEMAPHORES / \ CONDITION VARIABLES
semaphore_down_timeout, semaphore_up condvar_wait_timeout, condvar_signal
+--------------+ / \ +-----------+
| semaphore_t |<-+ +->| condvar_t |
+--------------+ +-----------+
| ^
| |
| +------+
V /
MUTEXES / READERS/WRITERS LOCKS
mutex_lock_timeout, mutex_unlock rwlock_reader/writer_lock_timeout, rwlock_unlock
+---------+ / +----------+
| mutex_t |------------------------------->| rwlock_t |
+---------+ / +----------+
| /
+------------------------+
//kernel/trunk/doc/preemption
0,0 → 1,58
Kernel makes it possible for a thread to be preempted anytime when
IRQ's are enabled on local CPU. This arrangement triggers a discussion
about its correctness and efficiency.
 
The correctness issue relates to the possibility of preempting a
thread holding a spinlock. It is natural to ask whether such a
preemption can lead to a deadlock. By proving the following lemma, we
will show that deadlock is actually not possible.
 
Lemma:
On condition that each spinning lock is always locked on the same
CPU priority level (either always with IRQ's disabled or always
with IRQ's enabled), otherwise correct code never deadlocks.
 
Proof:
Let all assumptions from the lemma hold.
Let us further assume that we have encountered a deadlock.
We will analyse all likely ways how that could have happened.
 
a) Deadlock happened between two CPUs. This means that there must
have been wrong lock-ordering. Code with lock-ordering problems is
considered incorrect and contradicts our assumptions.
b) Deadlock happened between two threads of execution executing on
the same CPU.
 
b1) If one thread of execution was servicing an interrupt and the
other was executing in thread context, our assumption that each
spinning lock is acquired always on the same CPU priority level is
violated.
b2) The last likely scenario is that the deadlock happened between
two threads executing on the same CPU with IRQ's enabled. Again,
this means that we were working with incorrect code because it
contained wrong ordering of lock operations.
Since there is no possibility left, except for trivial errors, we
have shown that the deadlock contradicts with our assumptions and
therefore is not possible.
 
Q.E.D.
Notes on the proof:
ad a) Deadlock between two CPUs is independent on the preemption
model. If we have this kind of deadlock, we would have had
the same kind of deadlock on an ordinary SMP system with
kernel preemption disabled.
This preemption model makes UP behave more like SMP because
it introduces some SMP specific specialities.
 
ad b2) Notice that the scenario when thread A acquires lock X and
gets preempted in favor of thread B which is trying to
acquire lock X, doesn't deadlock the two threads. Of course,
B won't be allowed to get X until A releases it, but that
will certainly happen because B too will sooner or later be
preempted. This scenario emphasizes the efficiency issues,
though.