On Mon, Dec 21, 2009 at 01:13:10PM -0600, Anthony Liguori wrote:
> 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.
>
You are exaggerating. If user want to update qemu it should exit old
one and re-run new one. Power off + startup, on the other hand, is defied
to be equivalent to ACPI reset by ACPI spec. In other words if devices
state as seen by vmstate after qemu start is different by even one bit
from the state after system_restart this is bug. This is completely
orthogonal to our firmware loading discussion.
> >>>>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.
Not all of it. We can completely change extboot interface, for instance,
and support migration if we will handle things right. We can fix bugs in
tpr patching without losing migration capability.
>
> 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.
>
No, not any bug is visible to the guest. Example: kvm currently configures
lvt0 to virtual wire inside qemu/kvm acpi code, but this should be done
by the BIOS on real HW. So suppose we fixed this bug and moved
initialization into the BIOS If we'll try to init new kvm with old BIOS
next OS boot will fail.
> 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.
>
We can't do guest visible changes in devices and FW and support
migration from older qemu. I think we agree on this. Non guest visible
changes are allowed for device emulation, you are trying to disallow it 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.
>
Please stop thinking so :) Especially about "user driven upgrades".
Why combine disadvantages of vitalization with pain of physical HW
management? Or may be next step will be to require uploading of CPU
microcode to take advantage of KVM/tcg bug fixes?
--
Gleb.
