qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize
Date: Wed, 19 Nov 2014 14:51:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

"Michael S. Tsirkin" <address@hidden> wrote:
> 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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]