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

[Anthony Liguori <anthony@codemonkey.ws>]

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