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

[Anthony Liguori]

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.

Regards,

Anthony Liguori

>
>> We might want to discuss two things here:
>> 
>> (1) The reset capability that OVMF exports via ACPI -- I agree that I
>> should be effecting the 0xCF9 thing in the appropriate table.
>
> Right. When doing that, we should bear in mind your observation (which I
> can confirm here) that boards in the field tend to have the RESET_REG
> filled in to point at 0xcf9, but *without* the corresponding flag set in
> the FADT flags to say that it's supported. It would be interesting to
> know if there's a *reason* for that, or if it's just the typical failure
> of BIOS engineers to actually read a specification or care about quality
> any further than "it boots one version of Windows when the wind is in an
> easterly direction".
>
>> (2) There's also one point (that I've ever seen) where OVMF itself
>> resets the platform. It is on the initial config TUI; there's a Reset
>> System option somewhere.
>
> It's a runtime services call. The kernel can use it too, and perhaps one
> might even argue that the kernel *should* use it by default, in
> preference to anything else? But again I suppose that's only true if
> Windows uses it; if Windows doesn't then we can expect that nobody out
> there bothers to *test* its implementation on real hardware :(
>
>> OTOH if the keyboard reset gets soft in qemu, then OVMF's hard reset
>> (the above code) will break. Maybe I could cycle between 0xCF9 and 0x64
>> in ResetCold(), starting with 0xCF9. (The full logic in the Linux kernel
>> seems a bit too much, see the list of source files in
>> <http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2093/focus=195441>.)
>
> Just cf9, kbc, cf9, kbc perhaps? http://mjg59.dreamwidth.org/3561.html
>
>
> -- 
> dwmw2