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.
