| 70,10 → 70,10 |
|---|
| |
| <para>Each address space consists of mutually disjunctive continuous |
| address space areas. Address space area is precisely defined by its |
| base address and the number of frames is contains.</para> |
| base address and the number of frames/pages is contains.</para> |
| |
| <para>Address space area also has special flags, that define behaviour |
| and permissions on the particular area. <itemizedlist> |
| <para>Address space area , that define behaviour and permissions on |
| the particular area. <itemizedlist> |
| <listitem> |
| |
| |
| 116,27 → 116,29 |
|---|
| |
| <para>When switching to the different task, kernel also require to |
| switch mappings to the different address space. In case TLB cannot |
| distinguish address space mappings, all mappings from the old address |
| space should be flushed, which can create certain uncessary |
| overhead.</para> |
| distinguish address space mappings, all mapping information in TLB |
| from the old address space must be flushed, which can create certain |
| uncessary overhead during the task switching. To avoid this, some |
| architectures have capability to segregate different address spaces on |
| hardware level introducing the address space identifier as a part of |
| TLB record, telling the virtual address space translation unit to |
| which address space this record is applicable.</para> |
| |
| <para>To avoid this, some architectures have capability to segregate |
| different address spaces on HW level introducing the ASID (address |
| space ID). On those architectures each TLB record contains an address |
| space identifier, that tells to which address space this record is |
| applicable.</para> |
| |
| <para>HelenOS kernel can take advantage of this hardware supported |
| identifier by having an ASID abstraction which is connected to the |
| corresponding architecture identifier. I.e. on ia64 kernel ASID is |
| built from RID (region identifier) and on the mips32 kernel ASID is |
| actually the hardware identifier.</para> |
| identifier by having an ASID abstraction which is somehow related to |
| the corresponding architecture identifier. I.e. on ia64 kernel ASID is |
| derived from RID (region identifier) and on the mips32 kernel ASID is |
| actually the hardware identifier. As expected, this ASID information |
| record is the part of <emphasis>as_t</emphasis> structure.</para> |
| |
| <para>Due to the hardware limitations ASID has limited length from 8 |
| bits on ia64 to 24 bits on mips32, which makes it impossible to use as |
| unique address space identifier for all tasks running in the system. |
| In such situations special ASID stealing algoritm is used, which takes |
| ASID from inactive task and assigns it to the active task.</para> |
| <para>Due to the hardware limitations, hardware ASID has limited |
| length from 8 bits on ia64 to 24 bits on mips32, which makes it |
| impossible to use it as unique address space identifier for all tasks |
| running in the system. In such situations special ASID stealing |
| algoritm is used, which takes ASID from inactive task and assigns it |
| to the active task.</para> |
| |
| <para><classname>ASID stealing algoritm here.</classname></para> |
| </section> |
| </section> |
| |
| 149,14 → 151,20 |
|---|
| <para>HelenOS kernel has two different approaches to the paging |
| implementation: <emphasis>4 level page tables</emphasis> and |
| <emphasis>global hash tables</emphasis>, which are accessible via |
| generic paging abstraction layer. This division was caused by the |
| major architectural differences between different platforms.</para> |
| generic paging abstraction layer. Such different functionality was |
| caused by the major architectural differences between supported |
| platforms. This abstraction is implemented with help of the global |
| structure of pointers to basic mapping functions |
| <emphasis>page_mapping_operations</emphasis>. To achieve different |
| functionality of page tables, corresponding layer must implement |
| functions, declared in |
| <emphasis>page_mapping_operations</emphasis></para> |
| |
| <formalpara> |
| <title>4-level page tables</title> |
| |
| <para>4-level page tables are the generalization of the hardware |
| capabilities of the certain platforms. <itemizedlist> |
| capabilities of several architectures.<itemizedlist> |
| <listitem> |
| ia32 uses 2-level page tables, with full hardware support. |
| </listitem> |