On 13 April 2018 at 08:52, Cédric Le Goater <c...@kaod.org> wrote: > 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.
I think in theory this should Just Work for allowing us to enable migration when the xilinx-spips device is using its execute-from-mmio feature (we would just need to remove the code that puts in the migration blocker). Xilinx folks -- do you have a test image for a board that uses xilinx-spips and exercises the execute-from-mmio code, that we can use to test migration/vmsave with? thanks -- PMM
