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

[Gleb Natapov <gleb@redhat.com>]

On Mon, Dec 21, 2009 at 07:24:43PM +0100, Sebastian Herbszt wrote:
> 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.
> 
It currently tries to do that, but state after reset is not exactly the
same as after qemu start. Each and every such difference is an instance
of a bug.

> >>>>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?
> 
There basically two approaches. One is you allow HW to change in such a
way that new FW is needed to init it and then you have to reload newer
FW after migration or you disallow HW changes that will prevent
old FW from configuring it and then you can use old FW after migration.

This is nothing special for KVM.

> 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.
> 
I am not talking about OS visible stuff.

--
			Gleb.