|
From: | Sebastian Herbszt |
Subject: | [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul. |
Date: | Mon, 21 Dec 2009 19:24:43 +0100 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |