Re: KVM entry failed, hardware error

[Johannes Bauer <dfnsonfsduifb@gmx.de>]

On 03.06.2012 15:43, Avi Kivity wrote:
> On 06/03/2012 04:01 PM, Johannes Bauer wrote:
>> On 03.06.2012 14:33, Avi Kivity wrote:
>>
>>>> when trying to install Windows7 in a qemu-kvm 1.0.1 installation on
>>>> Gentoo on my host running
>>>
>>> Is that a 32-bit or 64-bit Windows 7?
>>
>> 64 bit. But I've also (in despair) tried installing 32 Bit Windows 7,
>> with the exact same effect.
>>
>>>> EAX=00000010 EBX=00000080 ECX=00000000 EDX=00000080
>>>> ESI=0025da4a EDI=0007da4a EBP=00001f20 ESP=00000200
>>>> EIP=0000009b EFL=00000002 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
>>>> ES =0020 00000200 0000ffff 00009300
>>>> CS =b000 002b0000 0000ffff 0000f300
>>>
>>> Pre-unrestricted mode hosts require cs.selector (first number) * 16 ==
>>> cs.base (second number).  This clearly isn't the case here.
> 
> Gleb points out that cs.base == gdt.base, which doesn't make a lot of
> sense.  So some corruption has happened earlier.  Please follow
> http://www.linux-kvm.org/page/Tracing and post the last few thousand
> lines somewhere.  Trace a uniprocessor guest if the problem reproduces
> that way.

Tried that -- and failed miserably.

Something in the trace format appears to have changed. When using
trace-cmd report, I first get a parser warning:

trace-cmd: No such file or directory
  bad op token {
  failed to read event print fmt for kvm_emulate_insn
version = 6
CPU 0 is empty
cpus=4

The ENOENT errno doesn't correspond to that error, strace showed that
occuring much earlier in something unrelated. The warning is generated by:

#1  0x0000000000412c66 in process_op (event=0x6537c0, arg=0x6564f0,
tok=0x7fffffffd508) at /home/joe/qemu/trace/trace-cmd/parse-events.c:1686
#2  0x0000000000414eef in process_arg_token (event=0x6537c0,
arg=0x6564f0, tok=0x7fffffffd598, type=EVENT_OP) at
/home/joe/qemu/trace/trace-cmd/parse-events.c:2604
#3  0x0000000000412727 in process_arg (event=0x6537c0, arg=0x6564f0,
tok=0x7fffffffd598) at /home/joe/qemu/trace/trace-cmd/parse-events.c:1514
#4  0x00000000004146b4 in process_paren (event=0x6537c0, arg=0x6564f0,
tok=0x7fffffffd5f8) at /home/joe/qemu/trace/trace-cmd/parse-events.c:2352
#5  0x0000000000414eb0 in process_arg_token (event=0x6537c0,
arg=0x6564f0, tok=0x7fffffffd678, type=EVENT_DELIM) at
/home/joe/qemu/trace/trace-cmd/parse-events.c:2596
#6  0x0000000000412727 in process_arg (event=0x6537c0, arg=0x6564f0,
tok=0x7fffffffd678) at /home/joe/qemu/trace/trace-cmd/parse-events.c:1514
#7  0x0000000000414f87 in event_read_print_args (event=0x6537c0,
list=0x656490) at /home/joe/qemu/trace/trace-cmd/parse-events.c:2637
#8  0x000000000041524f in event_read_print (event=0x6537c0) at
/home/joe/qemu/trace/trace-cmd/parse-events.c:2723
#9  0x0000000000419040 in pevent_parse_event (pevent=0x63a0d0,
    buf=0x653390 "name: kvm_emulate_insn\nID:
29\nformat:\n\tfield:unsigned short
common_type;\toffset:0;\tsize:2;\tsigned:0;\n\tfield:unsigned char
common_flags;\toffset:2;\tsize:1;\tsigned:0;\n\tfield:unsigned char
common_preempt_"..., size=1053, sys=0x640790 "kvm") at
/home/joe/qemu/trace/trace-cmd/parse-events.c:4626
#10 0x000000000042190a in read_event_file (handle=0x63a030,
system=0x640790 "kvm", size=1053, print=0) at
/home/joe/qemu/trace/trace-cmd/trace-input.c:386
#11 0x0000000000421a90 in read_event_files (handle=0x63a030, print=0) at
/home/joe/qemu/trace/trace-cmd/trace-input.c:450
#12 0x0000000000421cb3 in tracecmd_read_headers (handle=0x63a030) at
/home/joe/qemu/trace/trace-cmd/trace-input.c:539
#13 0x000000000040c6a5 in trace_report (argc=2, argv=0x7fffffffd9d8) at
/home/joe/qemu/trace/trace-cmd/trace-read.c:1025
#14 0x00000000004057e7 in main (argc=2, argv=0x7fffffffd9d8) at
/home/joe/qemu/trace/trace-cmd/trace-cmd.c:147

The decoding that follows is complete garbage, which is why I think it's
of no use to you (i.e. the insn= part just displays some random
undefined memory from the looks).

Therefore, I've uploaded the compressed trace.dat file, so you can maybe
have a look why the "report" tool barfs and interpret it correctly. I
can't figure it out. The trace is here:

http://spornkuller.de/trace.dat.bz2

The trace was generated with a buffer of 40000 (double of what was given
in the example), when it was lower I had overruns. This way I had none.
Also, to simulate a single cpu, I've run qemu with "-smp 1", hopefully
that's correct.

>> I even tried to completing the installation on my laptop (which works),
>> then copy the image back on my desktop PC: Same error.
> 
> That should help the tracing effort.

Should I also generate a trace there and look for the corresponding
opcodes that fail on my main machine?

Best regards,
Joe