On Tue, Apr 23, 2013 at 08:21:29AM +0000, Zhanghaoyu (A) wrote:
> >> >> 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.
>
You do not expect registers to be the same each time, don't you? From
the quick glance there is nothing unusual about those states. Is VM UP
or SMP? If it is SMP you need to do "info register" for all cpus. Switch
between them with "cpu index" command. Do "x/i $pc" on each cpu too and
when you provide "info register" output do not cut GPR state.
--
Gleb.
--
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
