WebSVN – HelenOS-doc – Diff – /design/trunk/src/ap_arch.xml


<?xml version="1.0" encoding="UTF-8"?>
<appendix id="archspecs">
  <?dbhtml filename="arch.html"?>
 
  <title>Architecture Specific Notes</title>
 
  <section>
    <title>AMD64/Intel EM64T</title>
 
    <para>The amd64 architecture is a 64-bit extension of the older ia32
    architecture. Only 64-bit applications are supported. Creating this port
    was relatively easy, because it shares a lot of common code with ia32
    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 the ia32 architecture. The amd64 supports SYSCALL/SYSRET
      instructions. Upon encountering the 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 IA-32</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. The architecture 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>32-bit MIPS</title>
 
    <para>Both little and big endian kernels are supported. In order to test
    different page sizes, the mips32 page size was set to 16K. The mips32
    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 the mips32
      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>

Subversion Repositories HelenOS-doc

(root)/design/trunk/src/ap_arch.xml – Rev 130 → 133

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