diff options
| author | Anthony PERARD <anthony.perard@citrix.com> | 2019-12-19 15:43:22 +0000 |
|---|---|---|
| committer | Anthony PERARD <anthony.perard@citrix.com> | 2020-02-27 11:50:30 +0000 |
| commit | 5d4c954931ba62661c6a1bc16ce604a012a10007 (patch) | |
| tree | a66d547e8b1db3e3e717c494aae6c40ea893dcb9 /exec.c | |
| parent | 32d0b7be68216f130dc962533c6fc2f9ad848a8b (diff) | |
Memory: Only call ramblock_ptr when needed in qemu_ram_writeback
It is possible that a ramblock doesn't have memory that QEMU can
access, this is the case with the Xen hypervisor.
In order to avoid to trigger an assert, only call ramblock_ptr() when
needed in qemu_ram_writeback(). This should fix migration of Xen
guests that was broken with bd108a44bc29 ("migration: ram: Switch to
ram block writeback").
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20191219154323.325255-1-anthony.perard@citrix.com>
Diffstat (limited to 'exec.c')
| -rw-r--r-- | exec.c | 4 |
1 files changed, 2 insertions, 2 deletions
@@ -2116,14 +2116,13 @@ int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp) */ void qemu_ram_writeback(RAMBlock *block, ram_addr_t start, ram_addr_t length) { - void *addr = ramblock_ptr(block, start); - /* The requested range should fit in within the block range */ g_assert((start + length) <= block->used_length); #ifdef CONFIG_LIBPMEM /* The lack of support for pmem should not block the sync */ if (ramblock_is_pmem(block)) { + void *addr = ramblock_ptr(block, start); pmem_persist(addr, length); return; } @@ -2134,6 +2133,7 @@ void qemu_ram_writeback(RAMBlock *block, ram_addr_t start, ram_addr_t length) * specified as persistent (or is not one) - use the msync. * Less optimal but still achieves the same goal */ + void *addr = ramblock_ptr(block, start); if (qemu_msync(addr, length, block->fd)) { warn_report("%s: failed to sync memory range: start: " RAM_ADDR_FMT " length: " RAM_ADDR_FMT, |