On 08/19/2012 12:27 PM, Avi Kivity wrote:
On 08/17/2012 08:53 AM, Gerd Hoffmann wrote:
Hi,
It might be instruction emulator bug in KVM. Attached is the trace.
qemu-2047 [000] d..2 261.999076: kvm_entry: vcpu 0 qemu-2047 [000] ...1 261.999077: kvm_emulate_insn:f0000:6201:fb (real) qemu-2047 [000] d..2 261.999078: kvm_entry: vcpu 0 ##### CPU 3 buffer started #### qemu-2047 [003] ...1 411.367592: kvm_emulate_insn: 20000:26c:cb (prot16) qemu-2047 [003] ...1 411.367593: kvm_inj_exception: #GP (0x844) qemu-2047 [003] d..2 411.367594: kvm_entry: vcpu 0
This looks suspious. vcpu migration issue? Or just something missing in the trace?
Looks like tracing with a too-small buffer size. I generally trace using
trace-cmd record -e kvm -b 100000
and with fingers crossed.
The RET FAR instruction failure (which trace-cmd report decodes) is probably not the original failure.
In fact it is, we mis-emulated stack operations when SS.B=0 but the address size was 32-bits, and there are bits set in the top 16 bits of ESP.
Why ESP has bits set in the top 16 bits is another question. Is seabios polluting those bits?
On Sun, Aug 19, 2012 at 02:39:04PM +0300, Avi Kivity wrote:
On 08/19/2012 12:27 PM, Avi Kivity wrote:
On 08/17/2012 08:53 AM, Gerd Hoffmann wrote:
This looks suspious. vcpu migration issue? Or just something missing in the trace?
Looks like tracing with a too-small buffer size. I generally trace using
trace-cmd record -e kvm -b 100000
and with fingers crossed.
The RET FAR instruction failure (which trace-cmd report decodes) is probably not the original failure.
In fact it is, we mis-emulated stack operations when SS.B=0 but the address size was 32-bits, and there are bits set in the top 16 bits of ESP.
Why ESP has bits set in the top 16 bits is another question. Is seabios polluting those bits?
During the WinXP install/boot, when it makes 16bit calls it only resets the lower bits of %esp. It expects the 16bit code to only use %sp. Quite spectacularly, WinXP requires the top bits of %esp to not be mangled by the 16bit code.
SeaBIOS is very careful to not spuriously alter calling state. This includes backing up the top bits of %esp and restoring them on return.
-Kevin
On 08/19/2012 06:20 PM, Kevin O'Connor wrote:
On Sun, Aug 19, 2012 at 02:39:04PM +0300, Avi Kivity wrote:
On 08/19/2012 12:27 PM, Avi Kivity wrote:
On 08/17/2012 08:53 AM, Gerd Hoffmann wrote:
This looks suspious. vcpu migration issue? Or just something missing in the trace?
Looks like tracing with a too-small buffer size. I generally trace using
trace-cmd record -e kvm -b 100000
and with fingers crossed.
The RET FAR instruction failure (which trace-cmd report decodes) is probably not the original failure.
In fact it is, we mis-emulated stack operations when SS.B=0 but the address size was 32-bits, and there are bits set in the top 16 bits of ESP.
Why ESP has bits set in the top 16 bits is another question. Is seabios polluting those bits?
During the WinXP install/boot, when it makes 16bit calls it only resets the lower bits of %esp. It expects the 16bit code to only use %sp. Quite spectacularly, WinXP requires the top bits of %esp to not be mangled by the 16bit code.
SeaBIOS is very careful to not spuriously alter calling state. This includes backing up the top bits of %esp and restoring them on return.
Okay, I'll try to track down where this came from.
-
Avi Kivity -
Kevin O'Connor