* [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 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: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 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).