On 02/21/13 15:37, Anthony Liguori wrote: > David Woodhouse <dw...@infradead.org> 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