docs/devel/memory.rst

33 - RAM: a RAM region is simply a range of host memory that can be made available
44 - ROM: a ROM memory region works like RAM for reads (directly accessing
45   a region of host memory), and forbids writes. You initialize these with
48 - ROM device: a ROM device memory region works like RAM for reads
49   (directly accessing a region of host memory), but like MMIO for
53 - IOMMU region: an IOMMU region translates addresses of accesses made to it
54   and forwards them to some other target memory region.  As the name suggests,
60   into one unit.  For example, a PCI BAR may be composed of a RAM region
61   and an MMIO region.
70 - alias: a subsection of another region. Aliases allow a region to be
75   add the original region to multiple parents via
78   Aliases may point to any type of region, including other aliases,
82 - reservation region: a reservation region is primarily for debugging.
88 It is valid to add subregions to a region which is not a pure container
89 (that is, to an MMIO, RAM or ROM region). This means that the region
91 region which are not claimed by any subregion are handled by the
94 one of whose subregions is a low priority "background" region covering
96 Subregions cannot be added to an alias region.
101 Where the memory region is backed by host memory (RAM, ROM and
102 ROM device memory region types), this host memory needs to be
134 Region names
139 live migration sections.  This means that RAM region names need to have ABI
142 Region lifecycle
145 A region is created by one of the memory_region_init*() functions and
147 that the owner object remains alive as long as the region is visible to
148 the guest, or as long as the region is in use by a virtual CPU or another
152 After creation, a region can be added to an address space or a
156 Various region attributes (read-only, dirty logging, coalesced mmio,
157 ioeventfd) can be changed during the region lifecycle.  They take effect
158 as soon as the region is made visible.  This can be immediately, later,
161 Destruction of a memory region happens automatically when the owner
164 If however the memory region is part of a dynamically allocated data
165 structure, you should call object_unparent() to destroy the memory region
169 You must not destroy a memory region as long as it may be in use by a
172 call object_unparent() in the memory region owner's instance_finalize
174 memory region then should obviously be freed in the instance_finalize
179 - the memory region's owner had a reference taken via memory_region_ref
182 - the region is unparented, and has no owner anymore
184 - when address_space_unmap is called, the reference to the memory region's
189 object_unparent at any time for an alias or a container region.  It is
212 allows the region to overlap any other region in the same container, and
216 you can use memory_region_add_subregion_overlap() both to specify a region
218 background region that sits 'below' others (with a negative priority).
220 If the higher priority region in an overlap is a container or alias, then
221 the lower priority region will appear in any "holes" that the higher priority
222 region has left by not mapping subregions to that area of its address range.
224 aliases that leave holes then the lower priority region will appear in these
229 an MMIO region mapped at 0x0, size 0x6000, priority 1. B currently has two
247 C's region appears.
267 The memory core uses the following rules to select a memory region when the
270 - all direct subregions of the root region are matched against the address, in
273   - if the address lies outside the region offset/size, the subregion is
276     this leaf region