On 13.02.20 19:32, Peter Xu wrote: > On Thu, Feb 13, 2020 at 06:20:16PM +0100, David Hildenbrand wrote: >> Resizing while migrating is dangerous and does not work as expected. >> The whole migration code works on the usable_length of ram blocks and does >> not expect this to change at random points in time. >> >> Precopy: The ram block size must not change on the source, after >> ram_save_setup(), so as long as the guest is still running on the source. >> >> Postcopy: The ram block size must not change on the target, after >> synchronizing the RAM block list (ram_load_precopy()). >> >> AFAIKS, resizing can be trigger *after* (but not during) a reset in >> ACPI code by the guest >> - hw/arm/virt-acpi-build.c:acpi_ram_update() >> - hw/i386/acpi-build.c:acpi_ram_update() > > What can be the pre-condition of triggering this after reset? I'm > thinking whether QEMU can be aware of this "resizing can happen" > condition, then we could simply stop the migration from happening even > before the resizing happens. Thanks,
I think the condition is not known before the guest actually tries to read the relevant memory areas (which trigger the rebuilt+resize, and AFAIK, the new size depends on fw config done by the guest after the reset). So it's hard to "predict". In the precopy case it would be easier to abort (although, not simple AFAIKS), in the postcopy not so easy - because you're already partially running on the migration target. -- Thanks, David / dhildenb
