/[hurd]/hurd-l4/physmem/README
ViewVC logotype

Diff of /hurd-l4/physmem/README

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.1 by marcus, Tue Sep 9 21:43:12 2003 UTC revision 1.2 by neal, Tue Jan 11 18:15:26 2005 UTC
# Line 1  Line 1 
1  physmem  Introduction
2  =======  ============
3    
4  For now, this is only a small dummy program, not the real physical  physmem is the physical memory manager.  It has nothing to do with
5  memory server.  virtual memory management; that is the domain of the applications
6    themselves.
7    
8    The physical memory server provides three different resources: memory
9    control capabilities, containers and frames.
10    
11    Memory Control Ports
12    --------------------
13    
14    Memory control capabilities hold the right to guarantee a number of
15    frames.  A memory control capability may be split.  If a memory
16    control capability, A, holds the right to 100 frames and a new memory
17    control capability, B, is split from it to hold 10 frames, after the
18    operation, A guarantees 90 frames and B 10.
19    
20    In this scenario, the B is considered the child of the A.  If B is
21    destroyed it (as well as any memory control ports which have been
22    split from it) are absorbed back into A and any containers and frames
23    allocated using it are implicit deallocated.
24    
25    When a task is started, the starter may split its memory control
26    capability and give a copy of the new capability to the new task.
27    Alternatively, two tasks may share a memory control capability.
28    
29    In the former scenario, when the starter wants to terminate the child,
30    it may reclaim the frames by destroying the memory control capability.
31    
32    Containers
33    ----------
34    
35    physmem will allocate a container given a memory control capability.
36    When a frame is allocated into the container, the memory control
37    capability from which it was created it charged.
38    
39    A container represents a name space.  Valid container names (integers)
40    refer to bytes in a frame.  The contents of container are not directly
41    accessible to tasks.  A task must first map the contents of a
42    container into its virtual address space.
43    
44    Containers are used to share memory with other processes.  For
45    instance, in the case of a client of a filesystem.  The client creates
46    a container with a number of pages and sends it to the filesystem
47    which reads the data from backing store into the memory.  Since the
48    client may not be able to trust the server to not steal the physical
49    frames, the client must not give the capability to it.  Hence, a
50    weaker capability is provided which allows a server limited access to
51    a container.
52    
53    Frames
54    ------
55    
56    Frames are allocated in containers at particular addresses.  A client
57    may allocate any number of base page size frames at once (assuming
58    that there is enough credit in the memory control capability).
59    Internally, this range will immediately be converted to power of 2
60    frames.
61    
62    Once allocated, a task may request a map of a frame from the physical
63    memory server.  Maps are not guaranteed to be persistent: physmem may
64    rearrange physical memory to defragment it or to clear space in a
65    special zone (for instance, for DMA).  Frames, may, however, be pinned
66    in place for a limited amount of time.
67    
68    Frames are multiplexed as well as shared across multiple tasks, it is
69    useful to reallocate frames in place.  In this way, data structures
70    are not torn down just to be immediately recreated and gratuitous COWs
71    are not performed.  container_release disassociates frames in a region
72    with any shared frames.
73    
74    When a frame is deallocated, physmem may not immediately unmap it from
75    the client where it is safe to do so (i.e. without leaking information
76    or giving a task access which it should not have).  This is useful in
77    the case of highly shared read-only memory, e.g. shared libraries.
78    
79    Data Structures
80    ===============
81    
82    Given a container capability, a `struct container' can be derived from
83    it.  A container contains a btree of frame entries keyed by their
84    start index and size.
85    
86    A frame entry points to a `struct frame'.  Exactly one frame entry
87    exists for each mapping of a frame.  Hence, the frame entry is
88    per-mapping state and a frame is per-frame state.  Frames are
89    reference counted.

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.2

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26