diff options
| author | David Hildenbrand <david@redhat.com> | 2023-07-06 09:56:06 +0200 |
|---|---|---|
| committer | David Hildenbrand <david@redhat.com> | 2023-07-12 09:25:37 +0200 |
| commit | 1d44ff586f8a8e113379430750b5a0a2a3f64cf9 (patch) | |
| tree | 5b6f8570d84252fcc2559a9e134d23e6c8046312 /hw/virtio | |
| parent | ac23dd2f293c59a5cd2fb385162277b4a6aef769 (diff) | |
| download | qemu-1d44ff586f8a8e113379430750b5a0a2a3f64cf9.zip qemu-1d44ff586f8a8e113379430750b5a0a2a3f64cf9.tar.gz qemu-1d44ff586f8a8e113379430750b5a0a2a3f64cf9.tar.bz2 | |
softmmu/physmem: Warn with ram_block_discard_range() on MAP_PRIVATE file mapping
ram_block_discard_range() cannot possibly do the right thing in
MAP_PRIVATE file mappings in the general case.
To achieve the documented semantics, we also have to punch a hole into
the file, possibly messing with other MAP_PRIVATE/MAP_SHARED mappings
of such a file.
For example, using VM templating -- see commit b17fbbe55cba ("migration:
allow private destination ram with x-ignore-shared") -- in combination with
any mechanism that relies on discarding of RAM is problematic. This
includes:
* Postcopy live migration
* virtio-balloon inflation/deflation or free-page-reporting
* virtio-mem
So at least warn that there is something possibly dangerous is going on
when using ram_block_discard_range() in these cases.
Message-ID: <20230706075612.67404-2-david@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Diffstat (limited to 'hw/virtio')
0 files changed, 0 insertions, 0 deletions