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: Tue, 19 Feb 2013 19:39:35 +0000

On Tue, 2013-02-19 at 21:01 +0200, Gleb Natapov wrote:
> On Tue, Feb 19, 2013 at 06:48:41PM +0000, David Woodhouse wrote:
> > On Tue, 2013-02-19 at 20:41 +0200, Gleb Natapov wrote:
> > > Ah, yes of course. So does CSM takes the whole 0xe0000-0xfffff segment or
> > > it leaves OVMF code there somewhere. CSM reset code can jump into OVMF
> > > code in 0xe0000-0xfffff range and let it do the copy.
> > 
> > There is no OVMF code there; OVMF doesn't bother to put *anything* into
> > the RAM at 1MiB-δ unless there's a CSM.
> > 
> It runs from ROM and do not shadow itself?

It has no need to shadow itself. It loads the SeaBIOS CSM into the range
under 1MiB, if it wants to support legacy BIOS. Other than that, it
never cares about 16-bit code at all.

> > I'd rather implement the 0xcf9 reset properly in qemu though, and make
> > SeaBIOS use that (which it can do *sanely* as a CSM if it's in the ACPI
> > tables).
> > 
> I didn't follow that other discussion about hard/soft reset. How proper
> 0xcf9 reset will fix the problem? What will it do that system_reset does
> not?

A full *hard* reset (0xcf9) will reset the PAM configuration, and thus
the BIOS from 4GiB-δ *would* be shadowed into 1MiB-δ, by hardware.

But qemu doesn't *implement* a full hard reset; it doesn't reset the PAM
registers.

And making it do so the naïve way, by just hooking up a simple device
reset function to do so, would be wrong. Because it *shouldn't* happen
on a soft reset, such as a triple-fault or a reset triggered by the
keyboard controller. Since a soft reset was the only way to get back
from 80286 protected mode to 8086 mode, some software may actually *use*
it and expect it to behave correctly.

Hence the discussion about reset handling.

We'd need to fix SeaBIOS to use the 0xcf9 reset too; currently it'll sit
in an endless loop of keyboard-induced *soft* resets anyway, because it
tries that before 0xcf9.

And in fact it probably shouldn't use the hard-coded 0xcf9 reset; it
should use the one indicated by the ACPI RESET_REG field (which *is*
0xcf9... or should be).

-- 
dwmw2

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


reply via email to

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