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

[Anthony Liguori <anthony@codemonkey.ws>]

Gleb Natapov wrote:
>> It's not a matter of correctness IMHO.
>>
>>     
> Ah now I see what you mean. New FW has to be used after reboot because old
> one may not be able to init HW any longer.

I think we have two ways to view firmware.  The first would be to treat 
guest firmware as part of the guest.  What that means it that we should 
store all firmware in an nvram file, migrate the nvram file during 
migration, and provide a mechanism for the user to individually 
upgrade/replace the firmware.  We would never replace it from underneath 
the guest.  We only put things in nvram the first time it is 
initialized.  After that, it's entirely based on what the guest does.

On the one hand, this simplifies live migration, puts the user in more 
control over when there are firmware changes, gives us a very clear set 
of rules to follow with respect to compatibility.  On the other hand, it 
means we must provide backwards compatibility at the fw_cfg level and it 
means that any firmware upgrade has to be initiated by the user.  That 
means it's very likely that a user will not upgrade their firmware when 
upgrading qemu.  We could version the nvram and if we detect a guest 
image being moved between versions (without the use of -M xxx) we could 
automatically clear the nvram causing new firmware to be loaded.  Stable 
fixes for firmware though would require explicit action on the part of 
the guest.  This could be considered an advantage depending on your 
perspective.

The other option would be to treat guest firmware as part of the machine 
state.  The problem with this approach is that the firmware maintains 
state within the guest that qemu has no visibility into.  This makes it 
impossible for us to upgrade the firmware unless the guest is at a very 
well defined point in time (IOW, start-up or reset).  This has very 
different semantics than the rest of our machine and that's concerning.

I'm honestly on the fence about the two.  The first mechanism (nvram) is 
very appealing in that it matches hardware.  Having to rely on a guest 
to update it's firmware is concerning though.  The second mechanism is 
appealing from an ease of use perspective but the semantics of doing a 
live migration and getting a different firmware after reset/shutdown is 
rather scary from a support perspective.

>> I can understand an argument for predictability wrt wanted to be
>> able to guarantee that after the first reboot during a live
>> migration, you'll get the new firmware.  I'm not sure that's less
>> predictable then hard shutdown/start-up and I'm not sure I can
>> really make an argument for one way vs. the other.
>>
>>     
> system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
> just arguing if the same applies for the case that migration was done
> between boot and reset.
>   

It's not and it will never be completely.  By this logic, we should 
close the file descriptors for the block devices and try to reopen 
them.  It's certainly possible that someone does a mv of the block 
device and replaces it under the covers.

Likewise, if a user upgrades the firmware independently of the qemu 
version, it would need to reread the firmware from disk each boot.

Regards,

Anthony Liguori