Subversion Repositories HelenOS-doc

    <para>In HelenOS, address spaces are objects that encapsulate the

    following items:</para>

    <itemizedlist>

      <listitem>

        <para>address space identifier,</para>

      </listitem>

      <listitem>

        <para>page table PTL0 pointer and</para>

      </listitem>

      <listitem>

        <para>a set of mutually disjunctive address space areas.</para>

      </listitem>

    </itemizedlist>

    <para>Address space identifiers will be discussed later in this section.

    The address space contains a pointer to PTL0, provided that the

    architecture uses per address space page tables such as the hierarchical

    4-level page tables. The most interesting component is the B+tree of

    <section>

      <title>Address space areas</title>

      <para>Because an address space can be composed of heterogenous mappings

      such as userspace code, data, read-only data and kernel memory, it is

      further broken down into smaller homogenous units called address space

      areas. An address space area represents a continuous piece of userspace

      virtual memory associated with common flags. Kernel memory mappings do

      not take part in address space areas because they are hardwired either

      into TLBs or page tables and are thus shared by all address spaces. The

      flags are a combination of:</para>

      <itemizedlist>

        <listitem>

          <para><constant>AS_AREA_READ</constant>,</para>

        </listitem>

        <listitem>

          <para><constant>AS_AREA_WRITE</constant>,</para>

        </listitem>

        <listitem>

          <para><constant>AS_AREA_EXEC</constant> and</para>

        </listitem>

        <listitem>

          <para><constant>AS_AREA_CACHEABLE</constant>.</para>

        </listitem>

      </itemizedlist>

      <para>The <constant>AS_AREA_READ</constant> flag is implicit and cannot

      be removed. The <constant>AS_AREA_WRITE</constant> flag denotes a

      writable address space area and the <constant>AS_AREA_EXEC</constant> is

      used for areas containing code. The combination of

      <constant>AS_AREA_WRITE</constant> and <constant>AS_AREA_EXEC</constant>

      is not allowed. Some architectures don't differentiate between

      executable and non-executable mappings. In that case, the

      <constant>AS_AREA_EXEC</constant> has no effect on mappings created for

      the address space area in the page tables. If the flags don't have

      <constant>AS_AREA_CACHEABLE</constant> set, the page tables content of

      the area is created with caching disabled. This is useful for address

      space areas containing memory of some memory mapped device.</para>

      <para>Address space areas can be backed by a backend that provides

      virtual functions for servicing page faults that occur within the

      address space area, releasing memory allocated by the area and sharing

      the area. Currently, there are three backends supported by HelenOS:

      anonymous memory backend, ELF image backend and physical memory

      backend.</para>

      <formalpara>

        <title>Anonymous memory backend</title>

        <para>Anonymous memory is memory that has no predefined contents such

        as userspace stack or heap. Anonymous address space areas are backed

        by memory allocated from the frame allocator. Areas backed by this

        backend can be resized as long as they are not shared.</para>

      </formalpara>

      <formalpara>

        <title>ELF image backend</title>

        <para>Areas backed by the ELF backend are composed of memory that can

        be either initialized, partially initialized or completely anonymous.

        Initialized portions of ELF backend address space areas are those that

        are entirely physically present in the executable image (e.g. code and

        initialized data). Anonymous portions are those pages of the

        <emphasis>bss</emphasis> section that exist entirely outside the

        executable image. Lastly, pages that don't fit into the previous two

        categories are partially initialized as they are both part of the

        image and the <emphasis>bss</emphasis> section. The initialized

        portion does not need any memory from the allocator unless it is

        writable. In that case, pages are duplicated on demand during page

        fault and memory for the copy is allocated from the frame allocator.

        The remaining two parts of the ELF always require memory from the

        frame allocator. Non-shared address space areas backed by the ELF

        image backend can be resized.</para>

      </formalpara>

      <formalpara>

        <title>Physical memory backend</title>

        <para>Physical memory backend is used by the device drivers to access

        physical memory. No additional memory needs to be allocated on a page

        fault in this area and when sharing this area. Areas backed by this

        backend cannot be resized.</para>

      </formalpara>

      <section>

        <title>Memory sharing</title>

        <para>Address space areas can be shared provided that their backend

        supports sharing<footnote>

            <para>Which is the case for all currently supported

            backends.</para>

          </footnote>. When the kernel calls <code>as_area_share()</code>, a

        check is made to see whether the area is already being shared. If the

        area is already shared, it contains a pointer to the share info

        structure. The pointer is then simply copied into the new address

        space area and a reference count in the share info structure is

        incremented. Otherwise a new address space share info structure needs

        to be created. The backend is then called to duplicate the mapping of

        pages for which a frame is allocated. The duplicated mapping is stored

        in the share info structure B+tree called <varname>pagemap</varname>.

        Note that the reference count of the frames put into the

        <varname>pagemap</varname> must be incremented to prevent .</para>

      </section>

      <section>

        <title>Page faults</title>

        <para>When a page fault is encountered in the address space area, the

        address space page fault handler, <code>as_page_fault()</code>,

        invokes the corresponding backend page fault handler to resolve the

        situation. The backend might either confirm the page fault or perform

        a remedy. In the non-shared case, depending on the backend, the page

        fault can be remedied usually by allocating some memory on demand or

        by looking up the frame for the faulting translation in the ELF

        image.</para>

        <para>Shared address space areas need to consider the

        <varname>pagemap</varname> B+tree. First they need to make sure

        whether to mapping is not present in the <varname>pagemap</varname>.

        If it is there, then the frame reference count is increased and the

        page fault is resolved. Otherwise the handler proceeds similarily to

        the non-shared case. If it allocates a physical memory frame, it must

        increment its reference count and add it to the

        <varname>pagemap</varname>.</para>

      </section>

    </section>