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

[Blue Swirl]

2009/12/20 Gleb Natapov <address@hidden>:
> 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.

Then hw/pc.c could install a reset handler that clears all memory etc.