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

[Michael S. Tsirkin]

On Wed, Nov 19, 2014 at 11:45:15AM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" <address@hidden> wrote:
> > On Wed, Nov 19, 2014 at 11:11:26AM +0100, Juan Quintela wrote:
> >> "Michael S. Tsirkin" <address@hidden> wrote:
> >> > On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
> 
> 
> >> 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.
> 
> One thing is fix bugs, and a different one is completely change the way
> the tables/data are generated.

I want the ability to do both without keeping a ton of old code around.

> About keeping old bios forever, no.  Only while the machine types that
> depend on that BIOS are supported.  At the very point that they get not
> supported, we can drop it.

Still too much.
This is unsupportable and is not what we did historically.


> >
> >> 
> >> 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.
> 
> That is unfair.  It is the same that if I answer that your solution is
> just paper over the bugs that we have already foound and hope that there
> are no more bugs.  Do you think that describes your position?  Mine is
> also not described but your statement.

Then I don't understand. How do you suggest fixing BIOS bugs without
changing BIOS?
People have legitimate reasons to run compat machine types, and
they also need bugs fixed.

> >> > 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?
> 
> In general, I don't have specific examples:
> - when we have a string buffer, we sent/receive it with:
> 
>         VMSTATE_BUFFER(queue.data, PS2State),
> 
> We are sending whatever the size of queue.data is on source to whatever
> the queue.data is on destination.  We are hopping that they are the
> same.
> 
> In this case, if sizes are different, we got just a migration stream
> that is out of sync.  And if attacker modifies stream,  bad things could 
> happen.
> In the case of buffers/arrays (so far it appears that everyplace that
> recives a size from the network, it checks that it is small enough).
> 
> >
> >> > 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.
> 
> False.
> 
> qemu-2.2 -M pc-2.0 -> qemu-2.0 -M pc-2.0
> 
> You migrate that way, and you go from "new-good" BIOS to "bad-old" BIOS.

So? What is the point?

> I think the question here is, when we do this migration:
> 
> qemu-2.0 -M pc-2.0 -> qemu-2.2 -M pc-2.0
> 
> what BIOS should the second qemu use?  the one that existed on qemu-2.0
> time or the one that existed on qemu-2.2 time?  You can allow for
> bugfixes, but not for big changes like moving where the acpi tables were
> generated, etc, etc.

If you just ship old BIOS, you do not allow for bugfixes.

> I really think that we should use the BIOS from qemu-2.0 era.  And my
> understanding is that you defend that we should use the qemu-2.2 era
> BIOS.

Not only that.  We already do. And we don't intend to change that for 2.2.

> I think that is the whole point of the discussion.  Have I at least
> framed correctly what the discussion is about?
> 
> Later, Juan.

I think so.

Basically you want to freeze all firmware at time of release and never change it
for that machine type.
Correct?

This would be a regression, this is not how we did things in the past.

Real hardware lets users update firmware and so should virtual hardware.



-- 
MST