qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF


From: David Woodhouse
Subject: Re: [Qemu-devel] [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
Date: Mon, 18 Feb 2013 21:12:46 +0000

On Mon, 2013-02-18 at 14:11 -0500, Kevin O'Connor wrote:
> On Mon, Feb 18, 2013 at 07:04:08PM +0000, David Woodhouse wrote:
> > Well, what SeaBIOS already *does* is bash on the keyboard controller to
> > cause a reset. Which *ought* to work too; I have a patch to at least fix
> > *that*, by resetting the PAM setup in the i440.
> 
> The thing to be aware of here is that not all resets are equal.  There
> is old code out there that will force a reset to go from 80386 mode to
> 8086 mode (or was it 286 to 8086?).  So, some resets are really
> resumes (which must not alter memory) and some are real resets.  It's
> a mystery to me which is which, but I know this came up the last time
> the QEMU reset logic was discussed.

Hm, yes. It will have been 286 to 8086, because ISTR there was no
*other* way for the CPU to get back from 286 mode.

The i440fx data sheet (ยง3.0) appears to say that the default values are
loaded on a *hard* reset, not a soft reset. And a reset invoked by the
keyboard controller (as SeaBIOS does) is a *soft* reset. The only way to
do a *hard* reset from software that's mentioned in the datasheet is the
PMC turbo/reset control register (port 0x93). And that, presumably, is
chipset-dependent and not something we can easily use from the reset
vector without doing a bunch of hardware probing.

I suppose we could set it up in advance, during the *first*
initialisation. Just point a 'do_hard_reset()' function pointer at a
function of our choice, perhaps with the existing keyboard reset as a
default if we don't know of anything better.

So we could probably solve the software side, in the guest... but qemu
doesn't seem to distinguish between a hard reset and a soft reset, so
there's no way to make it reset the PAM registers in one case but not
the other. Does this reset for 286->8086 mode actually work in qemu at
all? Is qemu's "reset" a hard reset, or a soft reset?

I suppose given that the RCR is part of the I440FX, and the behaviour
that we want to vary for hard vs. soft reset is also within the I440FX,
we *could* contrive to reset the PAM registers *only* when reset via the
RCR. But if I propose a patch which does it that way, will someone hunt
me down and hurt me?

-- 
dwmw2

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


reply via email to

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