Re: [SeaBIOS] [edk2] [PATCH 0/8] OvmfPkg: reset-related changes
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 ... -- dwmw2
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
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
On Fri, 2013-02-22 at 20:25 +0100, Laszlo Ersek wrote:
... 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.
Hm yes, thank you for the reminder. It's all about working around that poxy KVM bug. So yes, this works around the *biggest* issue, and makes reboot work for the majority of cases. That's good enough for the short term, and when KVM is fixed the small remaining issue goes away too. -- dwmw2
participants (2)
-
David Woodhouse -
Laszlo Ersek