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

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

On Wed, Nov 19, 2014 at 02:51:38PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Wed, Nov 19, 2014 at 11:50:28AM +0100, Juan Quintela wrote:
> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> > On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
> >> >> "Michael S. Tsirkin" <mst@redhat.com> 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.
> 
> The code allows increasing of the ram regions if they are bigger on
> source.  Without further explanation.  Without knowing _why_ they are
> bigger on the other side.

Actually yes: devices that want this functionality need to call
the new API.
At the point where API is called, would be the best place to
put in an explanation why it should be resizeable.


> In general it would not work, even if it
> works on one particular case.  If they are bigger, it is because device
> code use that for something.  not necesarely something that can be
> ignored.
> 
> Later, Juan.

Absolutely.  And that is why callers get a callback notifying them about
resize.

See? You are arriving at my design step by step :)


-- 
MST