>> >> On Thu, Apr 18, 2013 at 12:00:49PM +0000, Zhanghaoyu (A) wrote:
>> >>> I start 10 VMs(windows xp), then running geekbench tool on them,
>> >>> about 2 days, one of them was reset, I found the reset operation
>> >>> is done by int kvm_cpu_exec(CPUArchState *env) {
>> >>> ...
>> >>> switch (run->exit_reason)
>> >>> ...
>> >>> case KVM_EXIT_SHUTDOWN:
>> >>> DPRINTF("shutdown\n");
>> >>> qemu_system_reset_request();
>> >>> ret = EXCP_INTERRUPT;
>> >>> break;
>> >>> ...
>> >>> }
>> >>>
>> >>> KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault handle handle_triple_fault().
>> >>>
>> >> How do you know that reset was done here? This is not the only
>> >> place where qemu_system_reset_request() is called.
>> I used gdb to debug QEMU process, and add a breakpoint in
>> qemu_system_reset_request(), when the case occurred, backtrace shown
>> as below,
>> (gdb) bt
>> #0 qemu_system_reset_request () at vl.c:1964
>> #1 0x00007f9ef9dc5991 in kvm_cpu_exec (env=0x7f9efac47100)
>> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/kvm-all.c:1602
>> #2 0x00007f9ef9d5b229 in qemu_kvm_cpu_thread_fn (arg=0x7f9efac47100)
>> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/cpus.c:759
>> #3 0x00007f9ef898b5f0 in start_thread () from /lib64/libpthread.so.0
>> #4 0x00007f9ef86fa84d in clone () from /lib64/libc.so.6
>> #5 0x0000000000000000 in ?? ()
>>
>> And, I add printk log in all places where KVM_EXIT_SHUTDOWN exit reason is set, only handle_triple_fault() was called.
>> >
>> >Make sure XP is not set to auto-reset in case of BSOD.
>> No, winxp is not set to auto-reset in case of BSOD. No Winxp event log reported.
>> >
>> >Best regards,
>> >Yan.
>> >
>> >>
>> >>> What causes the triple fault?
>> >>>
>> >> Are you asking what is triple fault or why it happened in your case?
>> What I asked is why triple fault happened in my case.
>> >> For the former see here: http://en.wikipedia.org/wiki/Triple_fault
>> >> For the later it is to late to tell after VM reset. You can run
>> >> QEMU with -no-reboot -no-shutdown. VM will pause instead of
>> >> rebooting and then you can examine what is going on.
>> Great thanks, I'll run QEMU with -no-reboot -no-shutdown options, if VM paused in my case, what should I examined?
>>
>Register state "info registers" in the monitor for each vcpu. Code around the instruction that faulted.
I ran the QEMU with -no-reboot -no-shutdown options, the VM paused When the case happened, then I info registers in QEMU monitor, shown as below,
CS =0008 00000000 ffffffff 00c09b00 DPL =0 CS32 [-RA]
SS =0010 00000000 ffffffff 00c09300 DPL =0 DS [-WA]
DS =0023 00000000 ffffffff 00c0f300 DPL =3 DS [-WA]
FS =0030 ffdff000 00001fff 00c09300 DPL =0 DS [-WA]
GS =0000 00000000 ffffffff 00c00000
LDT=0000 00000000 ffffffff 00c00000
TR =0028 80042000 000020ab 00008b00 DPL=0 TSS32-busy
GDT= 8003f000 000003ff
IDT= 8003f400 000007ff
CR0=8001003b CR2=760d7fe4 CR3=002ec000 CR4=000006f8
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000800
FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
In normal case, info registers in QEMU monitor, shown as below
CS =001b 00000000 ffffffff 00c0fb00 DPL=3 CS32 [-RA]
SS =0023 00000000 ffffffff 00c0f300 DPL=3 DS [-WA]
DS =0023 00000000 ffffffff 00c0f300 DPL=3 DS [-WA]
FS =0038 7ffda000 00000fff 0040f300 DPL=3 DS [-WA]
GS =0000 00000000 ffffffff 00000100
LDT=0000 00000000 ffffffff 00000000
TR =0028 80042000 000020ab 00008b00 DPL=0 TSS32-busy
GDT= 8003f000 000003ff
IDT= 8003f400 000007ff
CR0=80010031 CR2=0167fd20 CR3=0af00220 CR4=000006f8
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000800
FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=00a4000000a40a18 d830 FPR1=0012f9c07c90e900 e900
FPR2=7c910202ffffffff 5d40 FPR3=000001e27c903400 f808
FPR4=000005230012f87a 0000 FPR5=000000007c905d40 0001
FPR6=0000000100000000 0000 FPR7=a9dfde0000000000 4018
XMM00=7c917d9a0012f8d4000000007c900000 XMM01=0012f8740012f8740012f87a7c900000
XMM02=7c917de97c97b1787c917e3f0012f87a XMM03=0012fa687c80901a0012f91800006cfd
XMM04=7c9102027c9034007c9102087c90e900 XMM05=0000000c7c9000000012f9907c91017b
XMM06=00009a40000000000012f8780012f878 XMM07=6365446c745200007c91340500241f18
N.B. in two cases, CS DPL, SS DPL, FS DPL, FPR, XMM, FSW, ST, FTW values are quite distinct.
Thanks,
Zhang Haoyu
--
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
