* [Qemu-devel] in_asm substitute for accel=kvm:tcg @ 2013-09-17 11:37 Andriy Gapon 2013-09-17 12:32 ` Andreas Färber 0 siblings, 1 reply; 14+ messages in thread From: Andriy Gapon @ 2013-09-17 11:37 UTC (permalink / raw) To: qemu-devel It seems that when qemu is run with accel=kvm:tcg then -d in_asm does not produce anything. At least, with the qemu and kvm that I have access to. Is there any way to obtain equivalent logging in such a configuration? A note: a host and a guest are both amd64 (x86_64). Some background. I am trying to debug a problem with booting a FreeBSD VM. If acceleration is not used then the VM boots just fine. But with acceleration the boot process hangs somewhere in FreeBSD boot loader, judging from what I see on a screen. I suspect that there could be a problem with jumping from real to protected mode or some such "exotic" environment. To narrow down the possibilities I would like to examine execution trace and see where execution goes into the weeds. Thank you very much in advance. -- Andriy Gapon ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-17 11:37 [Qemu-devel] in_asm substitute for accel=kvm:tcg Andriy Gapon @ 2013-09-17 12:32 ` Andreas Färber 2013-09-17 14:33 ` Andriy Gapon 0 siblings, 1 reply; 14+ messages in thread From: Andreas Färber @ 2013-09-17 12:32 UTC (permalink / raw) To: Andriy Gapon; +Cc: qemu-devel Hi, Am 17.09.2013 13:37, schrieb Andriy Gapon: > > It seems that when qemu is run with accel=kvm:tcg then -d in_asm does not > produce anything. At least, with the qemu and kvm that I have access to. Are you saying that with accel=kvm:tcg when falling back to TCG, -d in_asm does not work? For accel=kvm it's expected not to produce any output since QEMU does not process any Translation Blocks then. > Is there any way to obtain equivalent logging in such a configuration? > A note: a host and a guest are both amd64 (x86_64). Under Linux, trace options for the kvm kernel module can be enabled via the file system. Regards, Andreas > > Some background. I am trying to debug a problem with booting a FreeBSD VM. If > acceleration is not used then the VM boots just fine. But with acceleration the > boot process hangs somewhere in FreeBSD boot loader, judging from what I see on > a screen. > I suspect that there could be a problem with jumping from real to protected mode > or some such "exotic" environment. To narrow down the possibilities I would > like to examine execution trace and see where execution goes into the weeds. > > Thank you very much in advance. > -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-17 12:32 ` Andreas Färber @ 2013-09-17 14:33 ` Andriy Gapon 2013-09-17 18:49 ` Gleb Natapov 0 siblings, 1 reply; 14+ messages in thread From: Andriy Gapon @ 2013-09-17 14:33 UTC (permalink / raw) To: Andreas Färber; +Cc: qemu-devel on 17/09/2013 15:32 Andreas Färber said the following: > Hi, > > Am 17.09.2013 13:37, schrieb Andriy Gapon: >> >> It seems that when qemu is run with accel=kvm:tcg then -d in_asm does not >> produce anything. At least, with the qemu and kvm that I have access to. > > Are you saying that with accel=kvm:tcg when falling back to TCG, -d > in_asm does not work? Yes, exactly. I see the same behavior with accel=kvm:tcg and accel=kvm:tcg. qemu version is 1.4.0. > For accel=kvm it's expected not to produce any output since QEMU does > not process any Translation Blocks then. > >> Is there any way to obtain equivalent logging in such a configuration? >> A note: a host and a guest are both amd64 (x86_64). > > Under Linux, trace options for the kvm kernel module can be enabled via > the file system. I'll try to google for this. -- Andriy Gapon ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-17 14:33 ` Andriy Gapon @ 2013-09-17 18:49 ` Gleb Natapov 2013-09-19 14:36 ` Andriy Gapon 0 siblings, 1 reply; 14+ messages in thread From: Gleb Natapov @ 2013-09-17 18:49 UTC (permalink / raw) To: Andriy Gapon; +Cc: Andreas Färber, qemu-devel On Tue, Sep 17, 2013 at 05:33:57PM +0300, Andriy Gapon wrote: > on 17/09/2013 15:32 Andreas Färber said the following: > > Hi, > > > > Am 17.09.2013 13:37, schrieb Andriy Gapon: > >> > >> It seems that when qemu is run with accel=kvm:tcg then -d in_asm does not > >> produce anything. At least, with the qemu and kvm that I have access to. > > > > Are you saying that with accel=kvm:tcg when falling back to TCG, -d > > in_asm does not work? > > Yes, exactly. I see the same behavior with accel=kvm:tcg and accel=kvm:tcg. > qemu version is 1.4.0. > > > For accel=kvm it's expected not to produce any output since QEMU does > > not process any Translation Blocks then. > > > >> Is there any way to obtain equivalent logging in such a configuration? > >> A note: a host and a guest are both amd64 (x86_64). > > > > Under Linux, trace options for the kvm kernel module can be enabled via > > the file system. > > I'll try to google for this. > http://www.linux-kvm.org/page/Tracing -- Gleb. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-17 18:49 ` Gleb Natapov @ 2013-09-19 14:36 ` Andriy Gapon 2013-09-19 16:53 ` Paolo Bonzini 0 siblings, 1 reply; 14+ messages in thread From: Andriy Gapon @ 2013-09-19 14:36 UTC (permalink / raw) To: Gleb Natapov; +Cc: Andreas Färber, qemu-devel on 17/09/2013 21:49 Gleb Natapov said the following: > http://www.linux-kvm.org/page/Tracing Gleb, thank you very much! Here's an interesting snippet from the trace: qemu-system-x86-4639 [003] 263925.182731: kvm_entry: vcpu 0 qemu-system-x86-4639 [003] 263925.182733: kvm_exit: reason IO_INSTRUCTION rip 0x89b1 info 3f60000 0 qemu-system-x86-4639 [003] 263925.182733: kvm_pio: pio_write at 0x3f6 size 1 count 1 qemu-system-x86-4639 [003] 263925.182734: kvm_userspace_exit: reason KVM_EXIT_IO (2) qemu-system-x86-4639 [003] 263925.182736: kvm_entry: vcpu 0 qemu-system-x86-4639 [003] 263925.182738: kvm_exit: reason EXCEPTION_NMI rip 0x934e info 0 80000b0d qemu-system-x86-4639 [003] 263925.182739: kvm_emulate_insn: 0:934e:0f 01 1e d6 95 (real) qemu-system-x86-4639 [003] 263925.182741: kvm_entry: vcpu 0 qemu-system-x86-4639 [003] 263925.182742: kvm_exit: reason EXCEPTION_NMI rip 0x9353 info 0 80000b0d qemu-system-x86-4639 [003] 263925.182743: kvm_emulate_insn: 0:9353:0f 01 16 d0 95 (real) qemu-system-x86-4639 [003] 263925.182745: kvm_entry: vcpu 0 qemu-system-x86-4639 [003] 263925.182746: kvm_exit: reason EXCEPTION_NMI rip 0x9358 info 0 80000b0d qemu-system-x86-4639 [003] 263925.182747: kvm_emulate_insn: 0:9358:0f 20 c0 (real) qemu-system-x86-4639 [003] 263925.182748: kvm_entry: vcpu 0 qemu-system-x86-4639 [003] 263925.182749: kvm_exit: reason EXCEPTION_NMI rip 0x935c info 0 80000b0d qemu-system-x86-4639 [003] 263925.182750: kvm_emulate_insn: 0:935c:0f 22 c0 (real) qemu-system-x86-4639 [003] 263925.182752: kvm_entry: vcpu 0 CPU:3 [2995 EVENTS DROPPED] qemu-system-x86-4639 [003] 263925.188830: kvm_emulate_insn: 0:9315: (real) qemu-system-x86-4639 [003] 263925.188831: kvm_emulate_insn: 0:9315: (real) qemu-system-x86-4639 [003] 263925.188831: kvm_emulate_insn: 0:9315: (real) ... ad infinitum I believe that the following log from unaccelerated qemu corresponds to the last few instructions: 0x0000000000009346: cli 0x0000000000009347: std 0x0000000000009348: xor %ax,%ax 0x000000000000934a: mov %ax,%ds 0x000000000000934c: mov %ax,%es 0x000000000000934e: lidtw -0x6a2a 0x0000000000009353: lgdtw -0x6a30 0x0000000000009358: mov %cr0,%eax 0x000000000000935b: inc %ax 0x000000000000935c: mov %eax,%cr0 ---------------- IN: 0x000000000000935f: ljmp $0x8,$0x9364 That is, 0x935c seems to be the last meaningful ip and the instruction seems to be enabling protected mode. Not sure how the code ends up at 0x9315 after that. And here is original assembly code: rret_tramp: movw $MEM_ESPR-0x08,%sp # Reset stack pointer pushal # Save gp regs pushl %gs # Save pushl %fs # seg pushl %ds # regs pushl %es pushfl # Save %eflags cli # Disable interrupts std # String ops dec xorw %ax,%ax # Reset seg movw %ax,%ds # regs movw %ax,%es # (%ss is already 0) lidt idtdesc # Set IDT lgdt gdtdesc # Set GDT mov %cr0,%eax # Switch to protected inc %ax # mode mov %eax,%cr0 # ljmp $SEL_SCODE,$rret_tramp.1 # To 32-bit code .code32 rret_tramp.1: xorl %ecx,%ecx # Zero movb $SEL_SDATA,%cl # Setup movw %cx,%ss # 32-bit movw %cx,%ds # seg movw %cx,%es # regs movl MEM_ESPR-0x04,%esp # Switch to kernel stack leal 0x44(%esp,1),%esi # Base of frame andb $~0x2,tss_desc+0x5 # Clear TSS busy movb $SEL_TSS,%cl # Set task ltr %cx # register I can provide full logs, etc. Please let me know what else I could do. Thanks! -- Andriy Gapon ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-19 14:36 ` Andriy Gapon @ 2013-09-19 16:53 ` Paolo Bonzini 2013-09-19 17:18 ` Andriy Gapon 2013-09-19 17:49 ` Andriy Gapon 0 siblings, 2 replies; 14+ messages in thread From: Paolo Bonzini @ 2013-09-19 16:53 UTC (permalink / raw) To: Andriy Gapon; +Cc: Andreas Färber, Gleb Natapov, qemu-devel Il 19/09/2013 16:36, Andriy Gapon ha scritto: > Not sure how the code ends up at 0x9315 after that. Events are dropped, probably corresponding to more emulation. > And here is original assembly code: > rret_tramp: movw $MEM_ESPR-0x08,%sp # Reset stack pointer > pushal # Save gp regs > pushl %gs # Save > pushl %fs # seg > pushl %ds # regs > pushl %es > pushfl # Save %eflags > cli # Disable interrupts > std # String ops dec > xorw %ax,%ax # Reset seg > movw %ax,%ds # regs > movw %ax,%es # (%ss is already 0) > lidt idtdesc # Set IDT > lgdt gdtdesc # Set GDT > mov %cr0,%eax # Switch to protected > inc %ax # mode > mov %eax,%cr0 # > ljmp $SEL_SCODE,$rret_tramp.1 # To 32-bit code > .code32 > rret_tramp.1: xorl %ecx,%ecx # Zero > movb $SEL_SDATA,%cl # Setup > movw %cx,%ss # 32-bit > movw %cx,%ds # seg > movw %cx,%es # regs > movl MEM_ESPR-0x04,%esp # Switch to kernel stack > leal 0x44(%esp,1),%esi # Base of frame > andb $~0x2,tss_desc+0x5 # Clear TSS busy > movb $SEL_TSS,%cl # Set task > ltr %cx # register > > I can provide full logs, etc. > Please let me know what else I could do. > Thanks! > -- 1) Can you try loading the kvm_intel module with emulate_invalid_guest_state=0? 2) What are the contents of fs and gs? Why are they not zeroed? Perhaps that is causing invalid guest state emulation to run, and then something is triggering a bug in emulate_invalid_guest_state itself. 3) What is at 0x9315? Paolo ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-19 16:53 ` Paolo Bonzini @ 2013-09-19 17:18 ` Andriy Gapon 2013-09-19 17:26 ` Paolo Bonzini 2013-09-19 17:49 ` Andriy Gapon 1 sibling, 1 reply; 14+ messages in thread From: Andriy Gapon @ 2013-09-19 17:18 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Andreas Färber, Gleb Natapov, qemu-devel on 19/09/2013 19:53 Paolo Bonzini said the following: > 1) Can you try loading the kvm_intel module with > emulate_invalid_guest_state=0? Will do. > 2) What are the contents of fs and gs? Why are they not zeroed? > Perhaps that is causing invalid guest state emulation to run, and then > something is triggering a bug in emulate_invalid_guest_state itself. I will try to find this out. > 3) What is at 0x9315? This I can answer immediately. It looks like this address even gets executed earlier: qemu-system-x86-12024 [002] 278153.809990: kvm_emulate_insn: 0:9315:ea 1a 93 00 00 (real) qemu-system-x86-12024 [002] 278153.809991: kvm_entry: vcpu 0 qemu-system-x86-12024 [002] 278153.809992: kvm_emulate_insn: 0:931a:31 c0 (real) I guess it's a jump to 931a. Puzzling that later it becomes a jump to self. -- Andriy Gapon ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-19 17:18 ` Andriy Gapon @ 2013-09-19 17:26 ` Paolo Bonzini 2013-09-19 18:05 ` Andriy Gapon 0 siblings, 1 reply; 14+ messages in thread From: Paolo Bonzini @ 2013-09-19 17:26 UTC (permalink / raw) To: Andriy Gapon; +Cc: Andreas Färber, Gleb Natapov, qemu-devel Il 19/09/2013 19:18, Andriy Gapon ha scritto: > on 19/09/2013 19:53 Paolo Bonzini said the following: >> 1) Can you try loading the kvm_intel module with >> emulate_invalid_guest_state=0? > > Will do. > >> 2) What are the contents of fs and gs? Why are they not zeroed? >> Perhaps that is causing invalid guest state emulation to run, and then >> something is triggering a bug in emulate_invalid_guest_state itself. > > I will try to find this out. > >> 3) What is at 0x9315? > > This I can answer immediately. It looks like this address even gets executed > earlier: > qemu-system-x86-12024 [002] 278153.809990: kvm_emulate_insn: 0:9315:ea 1a > 93 00 00 (real) > qemu-system-x86-12024 [002] 278153.809991: kvm_entry: vcpu 0 > qemu-system-x86-12024 [002] 278153.809992: kvm_emulate_insn: 0:931a:31 c0 > (real) > > I guess it's a jump to 931a. Yes, it is. > Puzzling that later it becomes a jump to self. I don't think that's what happens. It's more likely that for some reason the emulator mis-parses the instruction. Please confirm with "info cpus" that QEMU is looping there (just in case), and attach the output of "info registers" (you can use "-monitor stdio" to do this and to answer question 2 from my previous email). Paolo ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-19 17:26 ` Paolo Bonzini @ 2013-09-19 18:05 ` Andriy Gapon 0 siblings, 0 replies; 14+ messages in thread From: Andriy Gapon @ 2013-09-19 18:05 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Andreas Färber, Gleb Natapov, qemu-devel on 19/09/2013 20:26 Paolo Bonzini said the following: > I don't think that's what happens. It's more likely that for some > reason the emulator mis-parses the instruction. > > Please confirm with "info cpus" that QEMU is looping there (just in > case), and attach the output of "info registers" (you can use "-monitor > stdio" to do this and to answer question 2 from my previous email). (qemu) info registers EAX=00000010 EBX=00009335 ECX=00000000 EDX=00000000 ESI=000017fc EDI=000017c8 EBP=00045400 ESP=000017b8 EIP=00009315 EFL=00003002 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 ffffffff 00c09300 CS =0000 00000000 0000ffff 0000f300 SS =0000 00000000 0000ffff 0000f300 DS =0000 00000000 ffffffff 00c09300 FS =0a00 0000a000 ffffffff 00c0f300 GS =0a00 0000a000 ffffffff 00c0f300 LDT=0000 00000000 0000ffff 00008200 TR =0038 00005f98 00002067 00008b00 GDT= 00009590 0000003f IDT= 00005e00 00000197 CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 FCW=037f 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 (qemu) info cpus * CPU #0: pc=0x0000000000009315 thread_id=17463 But I can't 100% guarantee validity of these results. It seems that the first time I execute any monitor command it reports something consistently, but all subsequent invocations produce something different. So I restart the guest two times and each of the above commands was executes as the first command in monitor. -- Andriy Gapon ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-19 16:53 ` Paolo Bonzini 2013-09-19 17:18 ` Andriy Gapon @ 2013-09-19 17:49 ` Andriy Gapon 2013-09-22 6:31 ` Gleb Natapov 1 sibling, 1 reply; 14+ messages in thread From: Andriy Gapon @ 2013-09-19 17:49 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Andreas Färber, Gleb Natapov, qemu-devel on 19/09/2013 19:53 Paolo Bonzini said the following: > Il 19/09/2013 16:36, Andriy Gapon ha scritto: >> Not sure how the code ends up at 0x9315 after that. > > Events are dropped, probably corresponding to more emulation. I've got a trace without dropped events between the last "normal" instruction and the loop (and also including a snippet where the same code is executed without a problem): ... qemu-system-x86-12024 [003] 278157.048876: kvm_emulate_insn: 0:9366:b1 10 (prot32) qemu-system-x86-12024 [003] 278157.048877: kvm_entry: vcpu 0 qemu-system-x86-12024 [003] 278157.048878: kvm_emulate_insn: 0:9368:8e d1 (prot32) qemu-system-x86-12024 [003] 278157.048880: kvm_entry: vcpu 0 qemu-system-x86-12024 [003] 278157.048882: kvm_exit: reason CR_ACCESS rip 0x9312 info 0 0 qemu-system-x86-12024 [003] 278157.048883: kvm_cr: cr_write 0 = 0x10 qemu-system-x86-12024 [003] 278157.048885: kvm_entry: vcpu 0 qemu-system-x86-12024 [003] 278157.048886: kvm_emulate_insn: 0:9315:ea 1a 93 00 00 (real) qemu-system-x86-12024 [003] 278157.048887: kvm_entry: vcpu 0 qemu-system-x86-12024 [003] 278157.048888: kvm_emulate_insn: 0:931a:31 c0 (real) ... ... qemu-system-x86-12024 [003] 278157.048990: kvm_set_irq: gsi 4 level 0 source 0 qemu-system-x86-12024 [003] 278157.048991: kvm_pic_set_irq: chip 0 pin 4 (edge|masked) qemu-system-x86-12024 [003] 278157.048992: kvm_ioapic_set_irq: pin 4 dst 0 vec=0 (Fixed|physical|edge|masked) qemu-system-x86-12024 [003] 278157.049001: kvm_entry: vcpu 0 qemu-system-x86-12024 [003] 278157.049002: kvm_exit: reason IO_INSTRUCTION rip 0x1e675 info 3fd0008 0 qemu-system-x86-12024 [003] 278157.049005: kvm_emulate_insn: a000:1e675:ec (prot32) qemu-system-x86-12024 [003] 278157.049005: kvm_pio: pio_read at 0x3fd size 1 count 1 qemu-system-x86-12024 [003] 278157.049006: kvm_userspace_exit: reason KVM_EXIT_IO (2) qemu-system-x86-12024 [003] 278157.049024: kvm_entry: vcpu 0 qemu-system-x86-12024 [003] 278157.049027: kvm_exit: reason CR_ACCESS rip 0x9312 info 0 0 qemu-system-x86-12024 [003] 278157.049028: kvm_cr: cr_write 0 = 0x10 qemu-system-x86-12024 [003] 278157.049030: kvm_entry: vcpu 0 qemu-system-x86-12024 [003] 278157.049031: kvm_emulate_insn: 0:9315: (real) qemu-system-x86-12024 [003] 278157.049033: kvm_emulate_insn: 0:9315: (real) qemu-system-x86-12024 [003] 278157.049034: kvm_emulate_insn: 0:9315: (real) ... It's strange that no instruction gets reported in those repeating "0:9315: (real)" lines. It's like kvm is somehow losing track of what should be executed and just loops over the same ip without actually doing anything. -- Andriy Gapon ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-19 17:49 ` Andriy Gapon @ 2013-09-22 6:31 ` Gleb Natapov 2013-09-22 8:05 ` Andriy Gapon 0 siblings, 1 reply; 14+ messages in thread From: Gleb Natapov @ 2013-09-22 6:31 UTC (permalink / raw) To: Andriy Gapon; +Cc: Paolo Bonzini, Andreas Färber, qemu-devel On Thu, Sep 19, 2013 at 08:49:51PM +0300, Andriy Gapon wrote: > on 19/09/2013 19:53 Paolo Bonzini said the following: > > Il 19/09/2013 16:36, Andriy Gapon ha scritto: > >> Not sure how the code ends up at 0x9315 after that. > > > > Events are dropped, probably corresponding to more emulation. > > I've got a trace without dropped events between the last "normal" instruction > and the loop (and also including a snippet where the same code is executed > without a problem): Which kernel version is this? What BSD version? > ... > qemu-system-x86-12024 [003] 278157.048876: kvm_emulate_insn: 0:9366:b1 10 > (prot32) > qemu-system-x86-12024 [003] 278157.048877: kvm_entry: vcpu 0 > qemu-system-x86-12024 [003] 278157.048878: kvm_emulate_insn: 0:9368:8e d1 > (prot32) > qemu-system-x86-12024 [003] 278157.048880: kvm_entry: vcpu 0 > qemu-system-x86-12024 [003] 278157.048882: kvm_exit: reason > CR_ACCESS rip 0x9312 info 0 0 > qemu-system-x86-12024 [003] 278157.048883: kvm_cr: cr_write 0 = 0x10 > qemu-system-x86-12024 [003] 278157.048885: kvm_entry: vcpu 0 > qemu-system-x86-12024 [003] 278157.048886: kvm_emulate_insn: 0:9315:ea 1a > 93 00 00 (real) > qemu-system-x86-12024 [003] 278157.048887: kvm_entry: vcpu 0 > qemu-system-x86-12024 [003] 278157.048888: kvm_emulate_insn: 0:931a:31 c0 > (real) > ... ... > qemu-system-x86-12024 [003] 278157.048990: kvm_set_irq: gsi 4 level 0 > source 0 > qemu-system-x86-12024 [003] 278157.048991: kvm_pic_set_irq: chip 0 pin 4 > (edge|masked) > qemu-system-x86-12024 [003] 278157.048992: kvm_ioapic_set_irq: pin 4 dst 0 > vec=0 (Fixed|physical|edge|masked) > qemu-system-x86-12024 [003] 278157.049001: kvm_entry: vcpu 0 > qemu-system-x86-12024 [003] 278157.049002: kvm_exit: reason > IO_INSTRUCTION rip 0x1e675 info 3fd0008 0 > qemu-system-x86-12024 [003] 278157.049005: kvm_emulate_insn: a000:1e675:ec > (prot32) > qemu-system-x86-12024 [003] 278157.049005: kvm_pio: pio_read at > 0x3fd size 1 count 1 > qemu-system-x86-12024 [003] 278157.049006: kvm_userspace_exit: reason > KVM_EXIT_IO (2) > qemu-system-x86-12024 [003] 278157.049024: kvm_entry: vcpu 0 > qemu-system-x86-12024 [003] 278157.049027: kvm_exit: reason > CR_ACCESS rip 0x9312 info 0 0 > qemu-system-x86-12024 [003] 278157.049028: kvm_cr: cr_write 0 = 0x10 > qemu-system-x86-12024 [003] 278157.049030: kvm_entry: vcpu 0 > qemu-system-x86-12024 [003] 278157.049031: kvm_emulate_insn: 0:9315: (real) > qemu-system-x86-12024 [003] 278157.049033: kvm_emulate_insn: 0:9315: (real) > qemu-system-x86-12024 [003] 278157.049034: kvm_emulate_insn: 0:9315: (real) > ... > > It's strange that no instruction gets reported in those repeating "0:9315: > (real)" lines. It's like kvm is somehow losing track of what should be executed > and just loops over the same ip without actually doing anything. > > -- > Andriy Gapon -- Gleb. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-22 6:31 ` Gleb Natapov @ 2013-09-22 8:05 ` Andriy Gapon 2013-09-22 8:17 ` Gleb Natapov 0 siblings, 1 reply; 14+ messages in thread From: Andriy Gapon @ 2013-09-22 8:05 UTC (permalink / raw) To: Gleb Natapov; +Cc: Paolo Bonzini, Andreas Färber, qemu-devel on 22/09/2013 09:31 Gleb Natapov said the following: > Which kernel version is this? What BSD version? $ uname -a Linux kvm 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux FreeBSD is 9.x. -- Andriy Gapon ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-22 8:05 ` Andriy Gapon @ 2013-09-22 8:17 ` Gleb Natapov 2013-09-22 9:41 ` Andriy Gapon 0 siblings, 1 reply; 14+ messages in thread From: Gleb Natapov @ 2013-09-22 8:17 UTC (permalink / raw) To: Andriy Gapon; +Cc: Paolo Bonzini, Andreas Färber, qemu-devel On Sun, Sep 22, 2013 at 11:05:37AM +0300, Andriy Gapon wrote: > on 22/09/2013 09:31 Gleb Natapov said the following: > > Which kernel version is this? What BSD version? > > $ uname -a > Linux kvm 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 > x86_64 x86_64 GNU/Linux > That's pretty old kernel and there were a lot fixes in emulation since. Before we spend more time tracking this can you verify that the bug is reproducible with 3.11? -- Gleb. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] in_asm substitute for accel=kvm:tcg 2013-09-22 8:17 ` Gleb Natapov @ 2013-09-22 9:41 ` Andriy Gapon 0 siblings, 0 replies; 14+ messages in thread From: Andriy Gapon @ 2013-09-22 9:41 UTC (permalink / raw) To: Gleb Natapov; +Cc: Paolo Bonzini, Andreas Färber, qemu-devel on 22/09/2013 11:17 Gleb Natapov said the following: > On Sun, Sep 22, 2013 at 11:05:37AM +0300, Andriy Gapon wrote: >> on 22/09/2013 09:31 Gleb Natapov said the following: >>> Which kernel version is this? What BSD version? >> >> $ uname -a >> Linux kvm 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 >> x86_64 x86_64 GNU/Linux >> > That's pretty old kernel and there were a lot fixes in emulation since. > Before we spend more time tracking this can you verify that the bug is > reproducible with 3.11? Gleb, thank you very much -- right on the spot! With 3.11 the boot proceeds past that point. -- Andriy Gapon ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-09-22 9:42 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-09-17 11:37 [Qemu-devel] in_asm substitute for accel=kvm:tcg Andriy Gapon 2013-09-17 12:32 ` Andreas Färber 2013-09-17 14:33 ` Andriy Gapon 2013-09-17 18:49 ` Gleb Natapov 2013-09-19 14:36 ` Andriy Gapon 2013-09-19 16:53 ` Paolo Bonzini 2013-09-19 17:18 ` Andriy Gapon 2013-09-19 17:26 ` Paolo Bonzini 2013-09-19 18:05 ` Andriy Gapon 2013-09-19 17:49 ` Andriy Gapon 2013-09-22 6:31 ` Gleb Natapov 2013-09-22 8:05 ` Andriy Gapon 2013-09-22 8:17 ` Gleb Natapov 2013-09-22 9:41 ` Andriy Gapon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).