On Mon, Feb 18, 2013 at 02:33:23PM -0500, Kevin O'Connor wrote:
On Mon, Feb 18, 2013 at 09:17:05PM +0200, Gleb Natapov wrote:
On Mon, Feb 18, 2013 at 02:00:52PM -0500, Kevin O'Connor wrote:
Why not fix KVM so that it runs at fffffff0 after reset?
Because KVM uses VMX extension and VMX on CPU without "unrestricted guest" is not capable of doing so. Recent KVM code should be able to emulate real mode from the fffffff0 address instead of trying to enter vmx guest mode. I asked Laszlo to check if it is so, but even if KVM in 3.9 will work it will not fix all existent kernels out there. Old behaviour of approximating real mode by vm86 is still supported by using emulate_invalid_guest_state=false kernel module option and it will be nice if it will not break OVMF since it can be used as a workaround in case unemulated instruction is encountered.
For old versions of KVM, SeaBIOS can detect the loop and issue a shutdown. Not nice for users to have their "reboot" turn into a "poweroff", but likely better than just a hang.
The only thing SeaBIOS could do is setup the segment registers and then jump to fffffff0, which is a bit of work for the same end result.
If it will jump to fffffff0 KVM will jump to ffff0 instead :) It should restore pre-CSM loaded OVMF state and reset.
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?
-- Gleb.