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 10:19:22AM +0100, Juan Quintela wrote:


>> >>  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.
>
> This claim is very wrong.
> This would make is impossible to change BIOS bus without breaking
> migration.  Look at history of qemu, we change BIOS every release.

And we should do:

qemu -M pc-2.0 -L BIOS-2.0.bin

And that way for every version and every bios.  If they are the same,
a symlink does.  If they are not, different file.  And we would not have
this problems.

I fully agree that we have problems with BIOS every relase.  What we
don't agree is _what_ is the best way to fix the issue.


>> IMHO, b) is just asking for trouble.  Being able to go from random
>> changes to random changes look strange.
>
> Yes, it is hard to support.
> But it's a required feature, and in fact, it's an existing one.

>> 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.
>
> We have many devices that just get N from stream, do malloc(N), then read
> data from stream into it.
> You think it's unsafe? Go ahead and fix them all.

I am sure it is unsafe.  Fixing them requires incompatible changes, that
is the whole point :-(

> However, my patch does address your concern: callers specify the upper
> limit on the region size.
> Trying to migrate in a 1Gbyte region

Yes and no.  You are assuming that a guest launched with a device ram
size of 256KB receives a 512KB section and it knows what to do with it.

It knows what to do with the 256KB section, with the 512KB answer is
always a "perhaps".  It depends of what is on the extra space.

My solution would be that RAM/ROM sizes are always the same for
migration, so destination would always understand it.

It just forbids migrating between different machine types.  And I think
that is good, not bad.

Later, Juan.