On 02/22/13 15:55, David Woodhouse wrote: > On Fri, 2013-02-22 at 04:23 +0100, Laszlo Ersek wrote: >> Patches 1 to 6 upgrade the FADT to ACPI 2.0 and present the PIIX3 >> Reset Control Register in it. > > Hm. I can still trigger the soft reset loop in SeaBIOS, but perhaps not > in a circumstance that we care about... > > I've fixed Qemu to do the proper hard reset on 0xcf9 but not any other > reset method. I'm running with KVM on an old machine without > "unrestricted guest" support. > > I've fixed SeaBIOS to look for the ACPI RESET_REG and use it, and that > part *works*... but SeaBIOS only *sees* the ACPI table when we boot a > legacy OS. If I boot an EFI OS and then do a soft reset via the keyboard > controller ('echo -en \\xfe | dd of=/dev/port bs=1 seek=$((0x64))'), > SeaBIOS hasn't seen the ACPI tables, still uses the keyboard controller > as its first choice of reset method, and still does its reset loop as > before. > > Do we actually *care* about that? Do we expect any EFI OS to be doing a > keyboard reset instead of using ACPI or the runtime services Reset call?
http://thread.gmane.org/gmane.comp.emulators.qemu/195351/focus=2169 If you evaluate the pseudo-code there with the input you described above, I think we can conclude this is the KVM problem again, and that we shouldn't care. When you actually *want* soft reset, there's nothing qemu can do to cover up the problematic jump target that comes from the first part of the pseudo-code. Laszlo _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios