On 02/22/13 19:13, Laszlo Ersek wrote:
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.
... IOW, I think it's not important that SeaBIOS hasn't seen RESET_REG and cannot set things right by doing a real hard reset: under the circumstances you described, we shouldn't even *be* in SeaBIOS. When you do the soft reset within the UEFI OS, we should continue at 0xFFFFFFF0 (which is where the *UEFI* S3 resume could happen, if OVMF actually supported it).
Laszlo