Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Nov 20, 2014 at 02:35:14PM +0100, Markus Armbruster wrote:
> What am I missing here that can justify the complexity of partially
> overriding target configuration in the migration stream plus
> infrastructure for resizing memory?

The justification is that sizing it properly is an unsolved problem.

The difference with real hardware is that size of the flash depends
dynamically on the machine configuration.  And it's drastic: you can
have from 1 to 256 CPUs, 0 to 256 PCI bridges on each root, etc.

And I do believe the infrastructure will be handy for other
things.  For example, boot order ROM is now dynamic too,
with enough bootable devices it will start overflowing a page
and then we will have the same problem.

And the patchset is all of 150 lines with comments, the point
is that everything follows the same path: it's
enough to test one cross-version migration, e.g. 2.1->2.3 or whatever,
to make sure resizing works properly. Unlike extra modes which need
testing of each machine type with each guest.

-- 
MST