jcs.org
qemu with hax to log dma reads & writes
jcs.org/2018/11/12/vfio
docs/devel/memory.txt: Add section about RAM migration
Add a section to docs/devel/memory.txt about migration of
the backing memory for RAM regions.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1499438577-7674-12-git-send-email-peter.maydell@linaro.org
+31
+31
docs/devel/memory.txt
+31
docs/devel/memory.txt
···
91
91
the whole address range; this is often clearer and is preferred.
92
92
Subregions cannot be added to an alias region.
93
93
94
+
Migration
95
+
---------
96
+
97
+
Where the memory region is backed by host memory (RAM, ROM and
98
+
ROM device memory region types), this host memory needs to be
99
+
copied to the destination on migration. These APIs which allocate
100
+
the host memory for you will also register the memory so it is
101
+
migrated:
102
+
- memory_region_init_ram()
103
+
- memory_region_init_rom()
104
+
- memory_region_init_rom_device()
105
+
106
+
For most devices and boards this is the correct thing. If you
107
+
have a special case where you need to manage the migration of
108
+
the backing memory yourself, you can call the functions:
109
+
- memory_region_init_ram_nomigrate()
110
+
- memory_region_init_rom_nomigrate()
111
+
- memory_region_init_rom_device_nomigrate()
112
+
which only initialize the MemoryRegion and leave handling
113
+
migration to the caller.
114
+
115
+
The functions:
116
+
- memory_region_init_resizeable_ram()
117
+
- memory_region_init_ram_from_file()
118
+
- memory_region_init_ram_from_fd()
119
+
- memory_region_init_ram_ptr()
120
+
- memory_region_init_ram_device_ptr()
121
+
are for special cases only, and so they do not automatically
122
+
register the backing memory for migration; the caller must
123
+
manage migration if necessary.
124
+
94
125
Region names
95
126
------------
96
127