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 11:11:26AM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" <mst@redhat.com> 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.

You want to keep old bios around forever, and never fix
bugs in it?  I disagree, quite strongly.


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


You don't seem to want to fix them. Your solution is just to keep
bugs around forver.



> >> 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 :-(

I don't see the point, sorry.  Want to elaborate?

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

You basically ask firmware to be perfect, or want us to carry old bugs
around forever.  It makes things simple for migration code, at huge cost
elsewhere, and pain for users.

I don't want to maintain old bugs in ACPI, and same applies to
other firmware.

This is really the whole point of the patchset.
Keep bugs in device ram around until next reboot.
At that point users get new device with non buggy
behaviour.




-- 
MST