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 Wed, Nov 19, 2014 at 11:45:15AM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> > 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:
>> 
>> 
>> >> 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.

You want.

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

And we have failed spectacularly.  If what you do don't work
.... changing what you do?


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

if the change in the BIOS is big enough, they need to change also
machine type.  Is an easy as that.  You should not put a big change  in
BIOS without previous warning to the user.  This is independent of
migration.

Extreme example: You used to have BIOS and now move to UEFI. And don't
want to ship the old BIOS?  You consider that right?  if no, then we are
discussing about where is the limit, not if there is a limit.

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

You got new BIOS, and you got that they don't get the new non-buggy
behaviour.  They are running the old BIOS.  So, your solution don't fix
all problems.

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

We have qemu-2.0
And now we have qemu-2.0.1 and qemu-2.1
You know that some changes are not valid for qemu-2.0.1, right?  Some
for BIOS.

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

Bug fixes are ok.  Big changes no.  Think of what is permisible for
2.0.1 and not.  For instance, no new features allowed.

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

Back to square one.  We are failing with compatibility in the past.
Time to try new approachs?

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

But you can hibernate your laptop, update the firmware, and reboot?
Where the change can be anyting, like moving from traditional BIOS to
UEFI?

NO.  And for good reason.  If you are able to upgrade the BIOS while
hibernated, would it try to resume or just normal reboot?  Same for S3.

Later, Juan.