qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gleb Natapov
Subject: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
Date: Sun, 20 Dec 2009 17:52:01 +0200

On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >>More importantly though, what's the use-case here?
> >>
> >Use-case for what? This just what need to be done for correct HW
> >emulation.
> 
> Live migration is transparent to the guest.  The fact that firmware
> can upgrade itself without the guest doing anything is not something
> that really has a real world equivalent.
> 
> Even if it did, whether that automatic upgrade happens after a
> reboot vs. a hard power cycle is irrelevant.  The guest has no
> knowledge of the fact that the automatic firmware upgrade happened
> so if it gets delayed indefinitely, it doesn't matter.
> 
> 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. Suppose some bug in cirrus
emulation has being fixed and old vga bios should be accommodated to
those changes, if old vga bios will run after reset video output may not
work. Thinking about it we'll have the same problem if migration happens
during vga bios loading, but this is MUCH less likely to happen.

> 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.

> If anything, I can better understand the argument for not ever
> upgrading the firmware transparently.  Something like having a nvram
> file that we load all of the ROMs into, then do live migration and
> migrate the nvram file.  That would mean that we would have to be
> very careful in the future about supporting fw_cfg as a versioned
> interface.
This will prevent us from fixing bugs/adding features.

> 
> We would also want to provide a mechanism for a user to manually
> upgrade the firmware from within a guest if we went this route.
> 
> Regards,
> 
> Anthony Liguori

--
                        Gleb.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]