qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.


From: Gleb Natapov
Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
Date: Mon, 21 Dec 2009 19:43:12 +0200

On Mon, Dec 21, 2009 at 11:26:12AM -0600, Anthony Liguori wrote:
> On 12/21/2009 10:43 AM, Gleb Natapov wrote:
> >>There are some really ugly corner cases here.  For instance, guest
> >>is running and the user does a yum update which upgrades the qemu
> >>package.  This includes laying down a new bios.
> >>
> >>User eventually restarts guest, now we re-read BIOS and we're on a
> >>newer BIOS than the device model.  Badness ensues.
> >>
> >My package manager warns me that certain application need to be
> >restarted to work correctly after upgrade. This is hardly qemu specific
> >problem.
> 
> But again, I don't see when this is ever a feature that a user
> actually wants.  Unless you change restart to fork/exec+exit, you'll
> never have reset equivalent to power off + startup.  Can you
> advocate rereading roms and not advocate re-execing qemu?
Why I will never have reset equivalent to power off + startup? Are you
saying we are not capable of implementing spec correctly?

> >>And more importantly, what is the end-user benefit of doing this?
> >>
> >Working migration?
> 
> How does it fix migration? Migration needs to transfer the current
> roms in order to work.  A new version of qemu must support
> interacting with the old version of the firmware for migration to
> work.  What happens after reset has nothing to do with migration but
> because of the last requirement, the guest will obviously continue
> to work after reboot too.
I don't agree with your last requirement. Firmware goes hand in hand with
HW. Change that is only FW visible should not be backwards compatible.

--
                        Gleb.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]