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