On 12/21/2009 11:43 AM, Gleb Natapov wrote:
Why I will never have reset equivalent to power off + startup? Are you
saying we are not capable of implementing spec correctly?
No, I'm saying that if you want reset absolutely equivalent to power off
+ startup, then you need to fork() and re-exec qemu at startup since the
qemu binary may have changed while the guest was running.
My point behind this is I think that's equivalent to re-reading rom
contents from disk.
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.
I think we're papering over this issue. FW interfaces are guest visible
even though we've been pretending like they aren't.
SeaBIOS does not implement every possible BIOS function. I'm sure that
it will implement new functions over time. The presence of those
functions are certainly visible to the guest. Likewise, any bug or
added feature is visible to a guest.
More concretely, we have an internal OS that interacts very closely with
PXE roms (it makes use of UNDI). It's very aware of the difference
between etherboot and gPXE and it is also aware of different versions of
those two.
The arguments for saying FW is not guest visible is that FW interfaces
are well defined and do not change. The same is true for 99% of the
hardware we emulate. The reason we have guest visible changes is that
we're constantly improving and increasing the functionality of the
hardware. The same is true for FW.
I'm starting to think having an nvram with saved firmware and user
driven upgrades is the best approach for compatibility by far. I'm
still concerned though about the relatively complexity of having to
force users to upgrade their firmware.
Regards,
Anthony Liguori
