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?
> CSM code isn't supposed to be hardware-specific, but I suppose for the
> CSM running under KVM case we could *potentially* have a hack at the
> reset vector so that when we do find ourselves there under a buggy
> qemu/KVM implementation, it could set up a trampoline, reset the PAM
> registers manually (so that the KVM CS base address bug doesn't actually
> *hurt* us), then try again?
>
Yes, we are trying to come up with qemu/KVM specific hack here.
> 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?
--
Gleb.
