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?
If we've booted a legacy OS, it works fine. SeaBIOS gets invoked at 0xffff0 after a soft reset, uses the ACPI RESET_REG that it was given by OVMF, and does a proper reset...
# echo -en \xfe | dd of=/dev/port bs=1 seek=$((0x64)) Changing serial settings was 0/0 now 3/0 In resume (status=0) In 32bit resume Attempting a hard reboot Using ACPI reset reg rcr_write 6 (debug from qemu) SecCoreStartupWithStack(0xFFFE6000, 0x80000) File->Type: 0xB ...