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

[Juan Quintela <quintela@redhat.com>]

"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Nov 18, 2014 at 07:03:58AM +0100, Paolo Bonzini wrote:
>> 
>> 
>> On 17/11/2014 21:08, Michael S. Tsirkin wrote:
>> > Add API to manage on-device RAM.
>> > This looks just like regular RAM from migration POV,
>> > but has two special properties internally:
>> > 
>> >     - block is sized on migration, making it easier to extend
>> >       without breaking migration compatibility or wasting
>> >       virtual memory
>> >     - callers must specify an upper bound on size
>> 


>> Also, I am afraid that this design could make it easier to introduce
>> backwards-incompatible changes.
>
>
> Well the point is exactly to make it easy to make *compatible*
> changes.
>
> As I mentioned in the cover letter, it's not just ACPI.
> For example, we now change boot index dynamically.
> People using large fw cfg blobs, e.g. -initrd, would benefit from
> ability to change the blob dynamically.
> There could be other examples.

changing the size of the initrd, on the fly and wanting to migrate?  Is
that a real use case?  One that we should really care?

>>  I very much prefer to have
>> user-controlled ACPI information (coming from the command-line)
>> byte-for-byte identical for a given machine type.  Patches for that have
>> been on the list for almost two months, and it's not nice.
>> 
>> Paolo
>
> I guess we just disagree on whether these patches will effectively achieve
> this goal.  For example, some people want to rewrite iasl bits,
> generating everything in C. This will affect static bits too.
> I don't want to make every single change in code conditional
> on a machine type.

You can't migrate with a different BIOS on destination, period.  That is
what is making this whole issue complicated.  We have two clear options:

a- require BIOS & memory regions to be exactly the same in both sides.
   No need to add compat machinery.
b- trying to accomodate any potential change that could appear and use
   the same BIOS.

IMHO, b) is just asking for trouble.  Being able to go from random
changes to random changes look strange.

Just think about it for a second.  We are sending more data for some
regions that it was allocated.  And we just grow the regions and expect
that everything is going to be ok.  It is me, or this goes against every
security discipline that I can think of?

Later, Juan.