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: Sun, 20 Dec 2009 18:15:32 +0200

On Sun, Dec 20, 2009 at 04:08:32PM +0000, Blue Swirl wrote:
> On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov <address@hidden> wrote:
> > 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.
> 
> Some devices are careful enough to implement warm reset using a flag,
> see for example hw/sun4u.c. If you want more precision, you could
> introduce for example system_off_on with the memory clearing behavior
> you want.
I am not familiar with other architectures. All I am saying applies to
IBM PC only. Of course it is possible to design a system that impossible
to reset completely from software or by pushing reset button. (To design
general purpose computer like that one should be braindead though). On
IBM PC there are ways to reset different parts of the system and there
are ways to completely reset the system. We support only the later and
ACPI spec mandates this kind of reset if reset is done via ACPI.

--
                        Gleb.




reply via email to

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