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

[Juan Quintela]

"Michael S. Tsirkin" <address@hidden> wrote:
> On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
>> "Michael S. Tsirkin" <address@hidden> writes:


>> Since migration doesn't transport configuration, we require a compatibly
>> configured target, and that includes identical memory sizes.  RAM size
>> is explicit and the user's problem.  ROM size is generally implicit, and
>> we use machine type compatibility machinery to keep it fixed.  BIOS
>> changes can break migration only when we screw up or forget the
>> compatibility machinery.  Same as for lots of other stuff.  No big deal,
>> really, just a consequence of not migrating configuration.
>
> You don't get to maintain it, so it's no big deal for you.
>
> I see pain every single release and code is becoming spaghetty-like very
> quickly.  We thought it would work. It does not.  We do need a solution.
>
> And the pain is completely self-inflicted: we already migrate
> all necessary information!
> It's just a question of adjusting our datastructures to it.

migration from version foo to version bar.

You have two options here:

- You make source (foo) send the data on the format/sizes that destination
  (bar) wants.
- You make destination (bar) handle whatever source (foo) sends.

You need to put the "spagueti code" in foo or bar.  It needs to be in
one of the two places, because if that code was not needed, we would not
be discussion here,  see?

So, what we are discussing is where is better to put this code.  Emit
the code that destination expects, or make destination handle whatever
is sent.  Amound of mangling need to be basically the same.

Later, Juan.