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

[Sebastian Herbszt]

Gleb Natapov wrote:
> 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?

In the "POST failure (loop) with isapc and seabios" thread we have concluded
that the "system_reset" monitor command should trigger a power cycle, but
it currently doesn't. This same power cycle logic has to be implemented for ACPI
reset.

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

As stated before i don't like the idea of automagically upgrading the firmware
on reset, e.g. after a live migration to a newer qemu version. You have 
explained
that qemu-kvm needs this in order to work with live migration and changed hw
support because of bug fixes. Is this only needed in the kvm case?

Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios)
for licensing? It would be ugly if Windows wants you to re-activate after a 
reboot
following a migration to newer qemu version and therefore possibly changed 
tables
due to newer bios.

- Sebastian