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.
