qemu-devel
[Top][All Lists]
Advanced

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

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


From: Gleb Natapov
Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
Date: Mon, 21 Dec 2009 18:43:51 +0200

On Mon, Dec 21, 2009 at 10:40:56AM -0600, Anthony Liguori wrote:
> On 12/21/2009 01:32 AM, Gleb Natapov wrote:
> >On Sun, Dec 20, 2009 at 08:59:48PM -0500, Kevin O'Connor wrote:
> >>On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
> >>>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
> >>[...]
> >>>The other option would be to treat guest firmware as part of the machine
> >>>state.
> >>How about mixing the two?  Store the firmware in an nvram file and
> >>migrate it during migration, but clear the nvram and reload the
> >>firmware on each start-up and qemu reset.
> >>
> >That's precisely what I propose.
> 
> There are some really ugly corner cases here.  For instance, guest
> is running and the user does a yum update which upgrades the qemu
> package.  This includes laying down a new bios.
> 
> User eventually restarts guest, now we re-read BIOS and we're on a
> newer BIOS than the device model.  Badness ensues.
> 
My package manager warns me that certain application need to be
restarted to work correctly after upgrade. This is hardly qemu specific
problem.

> And more importantly, what is the end-user benefit of doing this?
> 
Working migration?

--
                        Gleb.




reply via email to

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