1,11 → 1,141 |
<?xml version="1.0" encoding="UTF-8"?> |
<appendix id="archspecs"> |
<?dbhtml filename="arch.html"?> |
<?dbhtml filename="arch.html"?> |
|
<title>Architecture specific notes</title> |
|
<section> |
<title>amd64</title> |
<title>AMD64/Intel EM64T</title> |
|
<para>amd64 bits</para> |
<para>The AMD64 architecture is a 64-bit extension of the older IA-32 |
architecture. Only 64-bit applications are supported. Creating this port |
was relatively easy, because it shares a lot of common code with IA-32 |
platform. However, the 64-bit extension has some specifics, which made the |
porting interesting.</para> |
|
<section> |
<title>Virtual Memory</title> |
|
<para>The AMD64 architecture uses standard processor defined 4-level |
page mapping of 4KB pages. The NX(no-execute) flag on individual pages |
is fully supported.</para> |
</section> |
|
<section> |
<title>TLB-only Paging</title> |
|
<para>All memory on the AMD64 architecture is memory mapped, if the |
kernel needs to access physical memory, a mapping must be created. |
During boot process the boot loader creates mapping for the first 20MB |
of physical memory. To correctly initialize the page mapping system, an |
identity mapping of whole physical memory must be created. However, to |
create the mapping it is unavoidable to allocate new - possibly unmapped |
- frames from frame allocator. The ia32 solves it by mapping first 2GB |
memory during boot process. The same solution on 64-bit platform becomes |
unfeasible because of the size of the possible address space.</para> |
|
<para>As soon as the exception routines are initialized, a special page |
fault exception handler is installed which provides a complete view of |
physical memory until the real page mapping system is initialized. It |
dynamically changes the page tables to always contain exactly the |
faulting address. The page then becomes cached in the TLB and on the |
next page fault the same tables can be utilized to handle another |
mapping.</para> |
</section> |
|
<section> |
<title>Mapping of Physical Memory</title> |
|
<para>The AMD64 ABI document describes several modes of program layout. |
The operating system kernel should be compiled in a |
<emphasis>kernel</emphasis> mode - the kernel is located in the negative |
2 gigabytes (0xffffffff80000000-0xfffffffffffffffff) and can access data |
anywhere in the 64-bit space. This wouldn't allow kernel to see directly |
more than 2GB of physical memory. HelenOS duplicates the virtual mapping |
of the physical memory starting at 0xffff800000000000 and accesses all |
external references using this address range.</para> |
</section> |
|
<section> |
<title>Thread Local Storage</title> |
|
<para>The code accessing thread local storage uses a segment register FS |
as a base. The thread local storage is stored in the hidden 64-bit part |
of the FS register which must be written using priviledged machine |
specific instructions. Special syscall to change this register is |
provided to user applications. The TLS address for this platform is |
expected to point just after the end of the thread local data.</para> |
</section> |
|
<section> |
<title>Fast SYSCALL/SYSRET Support</title> |
|
<para>The entry point for system calls was traditionally a speed problem |
on IA32 architecture. AMD64 supports a SYSCALL/SYSRET instructions. Upon |
encountering SYSCALL instruction, the processor changes privilege mode |
and transfers control to an address stored in machine specific register. |
Unlike other similar instructions it does not change stack to a known |
kernel stack, which must be done by the syscall entry routine. A hidden |
part of a GS register is provided to support the entry routine with data |
needed for switching to kernel stack.</para> |
</section> |
|
<section> |
<title>Debugging Support</title> |
|
<para>To provide developers tools for finding bugs, hardware breakpoints |
and watchpoints are supported. The kernel also supports self-debugging - |
it sets watchpoints on certain data and upon every modification |
automatically checks whether a correct value was written. It is |
worthwhile to mention, that since this feature was implemented, the |
watchpoint was never fired.</para> |
</section> |
</section> |
|
<section> |
<title>Intel IA32</title> |
|
<para>The IA32 architecture uses 4K pages and processor supported 2-level |
page tables. Along with AMD64 It is one of the 2 architectures that fully |
supports SMP configurations. IA32 is mostly similar to AMD64, it even |
shares a lot of code. The debugging support is the same as with AMD64. The |
thread local storage uses GS register.</para> |
</section> |
|
<section> |
<title>MIPS32</title> |
|
<para>Both little and big endian kernels are supported. In order to test |
different page size it was set to 16K. The MIPS architecture is TLB-only, |
the kernel simulates 2-level page tables. On processors that support it, |
lazy FPU context switching is implemented.</para> |
|
<section> |
<title>Thread Local Storage</title> |
|
<para>The thread local storage support in compilers is a relatively |
recent phenomena. The standardization of such support for MIPS platform |
is very new and even the newest versions of GCC cannot generate 100% |
correct code. Because of some weird MIPS processor variants, it was |
decided, that the TLS pointer will be gathered not from some of the free |
registers, but a special instruction was devised and the kernel is |
supposed to emulate it. HelenOS expects that the TLS pointer is in the |
K1 register. Upon encountering the reserved instruction exception and |
checking that the application is requesting a TLS pointer, it returns |
the contents of the K1 register. The K1 register is expected to point |
0x7000 bytes after the beginning of the thread local data.</para> |
</section> |
</section> |
|
<section> |
<title>Power PC</title> |
|
<para></para> |
</section> |
|
<section> |
<title>IA-64</title> |
|
<para></para> |
</section> |
</appendix> |