On Thu, Apr 19, 2018 at 06:32:07PM +0100, Peter Maydell wrote: > 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?
CC:ing Fred I got an image from Fred a while back ago, I probably still have it somewhere but I've totally forgotten the name for it. Fred, do you have the image or roughly remember the filename? Cheers, Edgar
