On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov <g...@redhat.com> 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.
