On Mon, Feb 18, 2013 at 02:00:52PM -0500, Kevin O'Connor wrote:
On Mon, Feb 18, 2013 at 08:31:01PM +0200, Gleb Natapov wrote:
Laszlo explained to me that the problem is that after reset we end up in SeaBIOS reset code instead of OVMF one. This is because kvm starts to execute from ffff0 instead of fffffff0 after reset and this memory location is modifying during CSM loading. Seabios solves this problem by detecting reset condition and copying pristine image of itself from the end of 4G to the end of 1M. OVMF should do the same, but with CSM it does not get control back after reset since Seabios reset vector is executed instead. Why not put OVMF reset code at reset vector in CSM built SeaBIOS to solve the problem?
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.
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.
-- Gleb.