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

[Michael S. Tsirkin]

On Wed, Nov 19, 2014 at 11:50:28AM +0100, Juan Quintela wrote:
> "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.

This is not what the patch does at all.  There is no special-casing
depending on machine type anywhere. Please review the code and respond
to actual patches.

-- 
MST