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. 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
