Re: [PATCH RFC] memory: Don't allow to resize RAM while migrating

[Peter Xu]

On Thu, Feb 13, 2020 at 08:42:23PM +0100, David Hildenbrand wrote:
> 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".

I chimmed in without much context, sorry if I'm going to ask naive
questions. :)

What I was asking is about why the resizing can happen.  A quick read
told me that it was majorly for easier extension of ROMs (firmware
updates?).  With that, I'm imaging a common case for memory
resizing...

  (1) Source QEMU runs VM on old host, with old firmware

  (2) Migrate source QEMU to destination new host, with new and bigger
      firmware

  (3) During the migration, the ROM size on the destination will still
      be the old, referring to ram_load_precopy(), as long as no
      system reset

  (4) After migration finished, when the system reboots, memory
      resizing happens with the new and bigger firmware loaded

And is this patch trying to fix/warn when there's a reboot during (3)
so the new size is discovered at a wrong time?  Is my understanding
correct?

> 
> 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.

Prior to this patch, would a precopy still survive with such an
accident (asked because I _feel_ like migrating a ramblock with
smaller used_length to the same ramblock with bigger used_length seems
to be fine?)?  Or we can stop the precopy and restart.  After this
patch, it'll crash the source VM (&error_abort specified in
memory_region_ram_resize()), which seems a bit more harsh?

Thanks,

-- 
Peter Xu