Rev 130 | Rev 137 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed
| Rev | Author | Line No. | Line |
|---|---|---|---|
| 122 | jermar | 1 | <?xml version="1.0" encoding="UTF-8"?> |
| 126 | jermar | 2 | <appendix id="archspecs"> |
| 130 | palkovsky | 3 | <?dbhtml filename="arch.html"?> |
| 4 | |||
| 133 | jermar | 5 | <title>Architecture Specific Notes</title> |
| 122 | jermar | 6 | |
| 7 | <section> |
||
| 130 | palkovsky | 8 | <title>AMD64/Intel EM64T</title> |
| 122 | jermar | 9 | |
| 133 | jermar | 10 | <para>The amd64 architecture is a 64-bit extension of the older ia32 |
| 130 | palkovsky | 11 | architecture. Only 64-bit applications are supported. Creating this port |
| 133 | jermar | 12 | was relatively easy, because it shares a lot of common code with ia32 |
| 130 | palkovsky | 13 | platform. However, the 64-bit extension has some specifics, which made the |
| 14 | porting interesting.</para> |
||
| 15 | |||
| 16 | <section> |
||
| 17 | <title>Virtual Memory</title> |
||
| 18 | |||
| 133 | jermar | 19 | <para>The amd64 architecture uses standard processor defined 4-level |
| 130 | palkovsky | 20 | page mapping of 4KB pages. The NX(no-execute) flag on individual pages |
| 21 | is fully supported.</para> |
||
| 22 | </section> |
||
| 23 | |||
| 24 | <section> |
||
| 25 | <title>TLB-only Paging</title> |
||
| 26 | |||
| 133 | jermar | 27 | <para>All memory on the amd64 architecture is memory mapped, if the |
| 130 | palkovsky | 28 | kernel needs to access physical memory, a mapping must be created. |
| 29 | During boot process the boot loader creates mapping for the first 20MB |
||
| 30 | of physical memory. To correctly initialize the page mapping system, an |
||
| 31 | identity mapping of whole physical memory must be created. However, to |
||
| 32 | create the mapping it is unavoidable to allocate new - possibly unmapped |
||
| 33 | - frames from frame allocator. The ia32 solves it by mapping first 2GB |
||
| 34 | memory during boot process. The same solution on 64-bit platform becomes |
||
| 35 | unfeasible because of the size of the possible address space.</para> |
||
| 36 | |||
| 37 | <para>As soon as the exception routines are initialized, a special page |
||
| 38 | fault exception handler is installed which provides a complete view of |
||
| 39 | physical memory until the real page mapping system is initialized. It |
||
| 40 | dynamically changes the page tables to always contain exactly the |
||
| 41 | faulting address. The page then becomes cached in the TLB and on the |
||
| 42 | next page fault the same tables can be utilized to handle another |
||
| 43 | mapping.</para> |
||
| 44 | </section> |
||
| 45 | |||
| 46 | <section> |
||
| 47 | <title>Mapping of Physical Memory</title> |
||
| 48 | |||
| 133 | jermar | 49 | <para>The amd64 ABI document describes several modes of program layout. |
| 130 | palkovsky | 50 | The operating system kernel should be compiled in a |
| 51 | <emphasis>kernel</emphasis> mode - the kernel is located in the negative |
||
| 52 | 2 gigabytes (0xffffffff80000000-0xfffffffffffffffff) and can access data |
||
| 53 | anywhere in the 64-bit space. This wouldn't allow kernel to see directly |
||
| 54 | more than 2GB of physical memory. HelenOS duplicates the virtual mapping |
||
| 55 | of the physical memory starting at 0xffff800000000000 and accesses all |
||
| 56 | external references using this address range.</para> |
||
| 57 | </section> |
||
| 58 | |||
| 59 | <section> |
||
| 60 | <title>Thread Local Storage</title> |
||
| 61 | |||
| 62 | <para>The code accessing thread local storage uses a segment register FS |
||
| 63 | as a base. The thread local storage is stored in the hidden 64-bit part |
||
| 64 | of the FS register which must be written using priviledged machine |
||
| 65 | specific instructions. Special syscall to change this register is |
||
| 66 | provided to user applications. The TLS address for this platform is |
||
| 67 | expected to point just after the end of the thread local data.</para> |
||
| 68 | </section> |
||
| 69 | |||
| 70 | <section> |
||
| 71 | <title>Fast SYSCALL/SYSRET Support</title> |
||
| 72 | |||
| 73 | <para>The entry point for system calls was traditionally a speed problem |
||
| 133 | jermar | 74 | on the ia32 architecture. The amd64 supports SYSCALL/SYSRET |
| 75 | instructions. Upon encountering the SYSCALL instruction, the processor |
||
| 76 | changes privilege mode and transfers control to an address stored in |
||
| 77 | machine specific register. Unlike other similar instructions it does not |
||
| 78 | change stack to a known kernel stack, which must be done by the syscall |
||
| 79 | entry routine. A hidden part of a GS register is provided to support the |
||
| 80 | entry routine with data needed for switching to kernel stack.</para> |
||
| 130 | palkovsky | 81 | </section> |
| 82 | |||
| 83 | <section> |
||
| 84 | <title>Debugging Support</title> |
||
| 85 | |||
| 86 | <para>To provide developers tools for finding bugs, hardware breakpoints |
||
| 87 | and watchpoints are supported. The kernel also supports self-debugging - |
||
| 88 | it sets watchpoints on certain data and upon every modification |
||
| 89 | automatically checks whether a correct value was written. It is |
||
| 90 | worthwhile to mention, that since this feature was implemented, the |
||
| 91 | watchpoint was never fired.</para> |
||
| 92 | </section> |
||
| 122 | jermar | 93 | </section> |
| 130 | palkovsky | 94 | |
| 95 | <section> |
||
| 133 | jermar | 96 | <title>Intel IA-32</title> |
| 130 | palkovsky | 97 | |
| 133 | jermar | 98 | <para>The ia32 architecture uses 4K pages and processor supported 2-level |
| 99 | page tables. Along with amd64 It is one of the 2 architectures that fully |
||
| 100 | supports SMP configurations. The architecture is mostly similar to amd64, |
||
| 101 | it even shares a lot of code. The debugging support is the same as with |
||
| 102 | amd64. The thread local storage uses GS register.</para> |
||
| 130 | palkovsky | 103 | </section> |
| 104 | |||
| 105 | <section> |
||
| 133 | jermar | 106 | <title>32-bit MIPS</title> |
| 130 | palkovsky | 107 | |
| 108 | <para>Both little and big endian kernels are supported. In order to test |
||
| 133 | jermar | 109 | different page sizes, the mips32 page size was set to 16K. The mips32 |
| 110 | architecture is TLB-only, the kernel simulates 2-level page tables. On |
||
| 111 | processors that support it, lazy FPU context switching is |
||
| 112 | implemented.</para> |
||
| 130 | palkovsky | 113 | |
| 114 | <section> |
||
| 115 | <title>Thread Local Storage</title> |
||
| 116 | |||
| 117 | <para>The thread local storage support in compilers is a relatively |
||
| 133 | jermar | 118 | recent phenomena. The standardization of such support for the mips32 |
| 119 | platform is very new and even the newest versions of GCC cannot generate |
||
| 120 | 100% correct code. Because of some weird MIPS processor variants, it was |
||
| 130 | palkovsky | 121 | decided, that the TLS pointer will be gathered not from some of the free |
| 122 | registers, but a special instruction was devised and the kernel is |
||
| 123 | supposed to emulate it. HelenOS expects that the TLS pointer is in the |
||
| 124 | K1 register. Upon encountering the reserved instruction exception and |
||
| 125 | checking that the application is requesting a TLS pointer, it returns |
||
| 126 | the contents of the K1 register. The K1 register is expected to point |
||
| 127 | 0x7000 bytes after the beginning of the thread local data.</para> |
||
| 128 | </section> |
||
| 129 | </section> |
||
| 130 | |||
| 131 | <section> |
||
| 132 | <title>Power PC</title> |
||
| 133 | |||
| 134 | <para></para> |
||
| 135 | </section> |
||
| 136 | |||
| 137 | <section> |
||
| 138 | <title>IA-64</title> |
||
| 139 | |||
| 140 | <para></para> |
||
| 141 | </section> |
||
| 122 | jermar | 142 | </appendix> |