/tags/0.1.0/SPARTAN/doc/arch/ia32 |
---|
0,0 → 1,33 |
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-8x Pentium 4 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 |
o Simics 2.2.19 |
/tags/0.1.0/SPARTAN/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 |
/tags/0.1.0/SPARTAN/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. |
/tags/0.1.0/SPARTAN/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 |
/tags/0.1.0/SPARTAN/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 |
/tags/0.1.0/SPARTAN/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 |
/tags/0.1.0/SPARTAN/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) |
/tags/0.1.0/SPARTAN/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 |
/tags/0.1.0/SPARTAN/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> |
/tags/0.1.0/SPARTAN/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. |
/tags/0.1.0/SPARTAN/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 | |
+---------+ / +----------+ |
| / |
+------------------------+ |
/tags/0.1.0/SPARTAN/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. |