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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
