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
0x0 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, 0x8)
File-Type: 0xB
...
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [edk2] [PATCH 0/8] OvmfPkg: reset-related changes
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
