qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Woodhouse
Subject: Re: [Qemu-devel] [edk2] [RFC PATCH] Distinguish between reset types
Date: Thu, 21 Feb 2013 09:15:10 +0000

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.

> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]