On 02/19/13 19:41, Gleb Natapov wrote:
On Tue, Feb 19, 2013 at 06:35:03PM +0000, David Woodhouse wrote:
On Tue, 2013-02-19 at 20:13 +0200, Gleb Natapov wrote:
I take it you mean copy 0xfffe0000 to 0xe0000? That would not be
fun.
SeaBIOS would need to detect that it's in the state (it's definitely not correct to do that on real-hardware or on "working" kvm instances), then setup a trampoline somewhere outside of 0xe0000-0xfffff to do the memcpy, jump to that trampoline, copy the memory, restore segment registers, and then jump to 0xfffffff0. That's a lot of kvm specific code to add to seabios as a workaround and it seems fragile anyway.
Isn't this exactly what qemu_prep_reset() is doing now?
No. It doesn't do the trampoline thing because it doesn't *have* to; it's copying an identical copy of the code back over itself.
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.
I think the only thing you could know about the UEFI environment (call-wise or jump-wise) while in the CSM is ReverseThunkCallSegment / ReverseThunkCallOffset. Theoretically those allow the CSM to call back into EfiCompatibility (32-bit protected mode environment).
Some problems: - Using the reverse thunk might only be allowed if we ended up in real mode coming through the forward thunk to begin with. When qemu/kvm simply jumps to 0xffff0 (reset request from guest OS), this doesn't hold.
- Currently no reverse thunk functions are defined in the CSM spec, and the implementation in TianoCore seems ... absent. The directory "IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Ipf" appears to contain some incomplete Itanium assembly.
Anyway David is fixing qemu to reset the PAMs at hard reset, so OVMF should show up again in the f-segment, accomodating older kvm hosts.
Laszlo