migration: discard non-migratable RAMBlocks
commitb895de502717b83b4e5f089df617cb23530c4d2d
authorCédric Le Goater <clg@kaod.org>
Mon, 14 May 2018 06:57:00 +0000 (14 08:57 +0200)
committerJuan Quintela <quintela@redhat.com>
Mon, 4 Jun 2018 03:46:15 +0000 (4 05:46 +0200)
treeee018e3b83760d9679c768672d0b610522e76933
parentf548222c24342ca74689de7794f9006b43f86a54
migration: discard non-migratable RAMBlocks

On the POWER9 processor, the XIVE interrupt controller can control
interrupt sources using MMIO to trigger events, to EOI or to turn off
the sources. Priority management and interrupt acknowledgment is also
controlled by MMIO in the presenter sub-engine.

These MMIO regions are exposed to guests in QEMU with a set of 'ram
device' memory mappings, similarly to VFIO, and the VMAs are populated
dynamically with the appropriate pages using a fault handler.

But, these regions are an issue for migration. We need to discard the
associated RAMBlocks from the RAM state on the source VM and let the
destination VM rebuild the memory mappings on the new host in the
post_load() operation just before resuming the system.

To achieve this goal, the following introduces a new RAMBlock flag
RAM_MIGRATABLE which is updated in the vmstate_register_ram() and
vmstate_unregister_ram() routines. This flag is then used by the
migration to identify RAMBlocks to discard on the source. Some checks
are also performed on the destination to make sure nothing invalid was
sent.

This change impacts the boston, malta and jazz mips boards for which
migration compatibility is broken.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
exec.c
include/exec/cpu-common.h
migration/postcopy-ram.c
migration/ram.c
migration/savevm.c