[SeaBIOS] [edk2] [PATCH 0/8] OvmfPkg: reset-related changes

[Laszlo Ersek]

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