Re: [Qemu-devel] [edk2] [RFC PATCH] Distinguish between reset types

[Laszlo Ersek]

On 02/21/13 15:37, Anthony Liguori wrote:
> David Woodhouse <address@hidden> writes:
> 
>> On Thu, 2013-02-21 at 02:10 +0100, Laszlo Ersek wrote:
>>> On 02/21/13 00:55, David Woodhouse wrote:
>>>> Well... your test now works because of the bug that Anthony is trying to
>>>> fix :)
>>>
>>> I don't believe so,
>>
>> Ok, for the *specific* variant of the test that you did.
>>
>> But there are many tests you could have done which *do* only work
>> because of the bug that Anthony is trying to fix. From what you say, it
>> looks like if the kernel had used the EFI runtime services 'ResetSystem'
>> call, that "should" have failed too since it only does a KBC soft
>> reset.
> 
> Help me understand where we're at.  If you fix the bugs in UEFI and
> SeaBIOS, and I correct the reset patches I pointed you at earlier, we're
> good?  Or is the lack of big real mode at startup on non-unrestricted
> mode boxes also a problem?
> 
> I never quite understood how the two related to each other in this thread.

In addition to what David wrote, I'll try to formalize the problem I ran
into.

    assert(firmware is OVMF + SeaBIOS CSM);
    assert(at 0xFFFFFFF0, OVMF reset vector / startup code is visible);
    assert(reset, soft or hard, was requested);

    if (!kvm_enabled() ||
        (host_cpu_supports_unrestricted_guest() &&
         !host_admin_has_disabled_unrestricted_guest()) ||
        kvm_is_recent_and_doesnt_approximate_real_mode_with_vm86()) {
        jump_target = 0xFFFFFFF0;
    } else {
        /* KVM problem hits */
        jump_target = 0xFFFF0;
    }

    if (reset_kind_is_hard() &&
        qemu_is_recent_and_clears_i440FX_PAM_regs_at_hard_reset()) {
        /* workable */
        visible_at_FFFF0h = low_image_of_OVMF_reset_vector_from_ROM;
    } else {
        /* unusable under OVMF+SeaBIOS CSM */
        visible_at_FFFF0h = SeaBIOS_reset_code_retriggering_reset;
    }

    jump_to(jump_target);

If kvm is disabled, or it is enabled and the host has support for
unrestricted guest and the sysadmin hasn't disabled UG, or the host is
old or UG is disabled BUT KVM fully-emulates real mode instead of
approximating it, *then* we jump to the correct OVMF reboot code at hard
reset time, and we don't care what's visible at 0xFFFF0 at all.

If however the KVM problem affects us, then we *do* care about what's
visible at 0xFFFF0. If we want hard reset, and qemu is recent and resets
the PAM regs at hard reset, then the incorrectly low jump_target value
ultimately points into good code.

Otherwise at 0xFFFF0 we'll find a vestigial SeaBIOS reset vector from
the CSM binary, which just re-requests a reset, and we reenter the above
pseudo-code at the top. (Infinite loop, if SeaBIOS requests a soft reset
*or* it requests a hard one but qemu doesn't have the PAM fix.)

Since
- I like kvm, and
- I cannot easily change my hardware (which doesn't support UG), and
- I prefer to run the RHEL-6 kernel which has "old" KVM,
I depend on David's fix for the PAM registers.

Laszlo