Re: [Qemu-devel] VM can not boot after commit 235e898

[Gleb Natapov]

On Wed, Jul 24, 2013 at 05:31:14PM +0200, Alexander Graf wrote:
> On 07/24/2013 05:21 PM, Gleb Natapov wrote:
> >On Wed, Jul 24, 2013 at 05:16:09PM +0200, Paolo Bonzini wrote:
> >>Il 24/07/2013 11:58, Alexander Graf ha scritto:
> >>>>>No QEMU or kvm crashes, no error message printed, I mean it just hangs, 
> >>>>>even no BIOS information are printed.
> >>>>>And "top" shows QEMU consumes 100% cpu.
> >>>>>
> >>>>>When I define DEBUG_KVM in kvm-all.c, and run QEMU(this time I boot a 
> >>>>>normal OS disk),
> >>>>># x86_64-softmmu/qemu-system-x86_64 -enable-kvm -hda 
> >>>>>/mnt/nfs/Images/debian-append.img
> >>>>>kvm_init_vcpu
> >>>>>kvm_cpu_exec()
> >>>>>handle_io
> >>>>>handle_io
> >>>>>handle_io
> >>>>>handle_io
> >>>>>
> >>>>>Only 4 debug messages(handle_io) are printed, then nothing is shown, and 
> >>>>>"top" shows QEMU process uses 100% CPU.
> >>>After this we're running in an endless loop of:
> >>>
> >>>  qemu-system-x86-9298  [003] ...1 162090.918845: kvm_emulate_insn: 
> >>> f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
> >>>  qemu-system-x86-9298  [003] d..2 162090.918846: kvm_entry: vcpu 0
> >>>
> >>>   (qemu) x /i $pc
> >>>   0x00000000000fc489:  ljmpl  $0x8,$0xfc491
> >>>
> >>>With current master, qemu-system-x86_64 -enable-kvm is broken on at least 
> >>>3.7 kernels (openSUSE 12.3).
> >>>
> >>>Gleb, I don't remember all the glorious details of ljmpl, but would it 
> >>>have to raise an MMIO request for a read-only memory slot which it fails 
> >>>to do?
> >>The point of KVM_CAP_READONLY_MEM should be that it doesn't.
> >>
> >Yes, it should not. Can you provide complete trace of kvm and kvmmmu
> >event up until failure?
> 
> Sure! These are all trace events up to the loop that I was able to
> fetch from the "kvm" and "kvmmmu" event bucket in
> /sys/kernel/debug/tracing.
> 
You should start using trace-cmd :) It even disassembles for you.

>  qemu-system-x86-13150 [000] d..2 185370.441825: kvm_entry: vcpu 0
>  qemu-system-x86-13150 [000] d..2 185370.441826: kvm_exit: reason 
> EXCEPTION_NMI rip 0xc486 info 0 80000b0d
>  qemu-system-x86-13150 [000] ...1 185370.441826: kvm_emulate_insn: 
> f0000:c486:0f 22 c0 (real)
This mov CR0 that sets PE bit.

>  qemu-system-x86-13150 [000] d..2 185370.441829: kvm_entry: vcpu 0
>  qemu-system-x86-13150 [000] ...1 185370.441830: kvm_emulate_insn: 
> f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
Here jmp is emulated because vcpu state is invalid, but for some reason
emulation does not fail and does not succeed. Never saw such thing
before. Are you saying configuring BIOS memslot differently solves the
problem?
 
>  qemu-system-x86-13150 [000] d..2 185370.441833: kvm_entry: vcpu 0
>  qemu-system-x86-13150 [000] ...1 185370.441833: kvm_emulate_insn: 
> f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
>  qemu-system-x86-13150 [000] d..2 185370.441834: kvm_entry: vcpu 0
>  qemu-system-x86-13150 [000] ...1 185370.441835: kvm_emulate_insn: 
> f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
>  qemu-system-x86-13150 [000] d..2 185370.441835: kvm_entry: vcpu 0
>  qemu-system-x86-13150 [000] ...1 185370.441836: kvm_emulate_insn: 
> f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
>  qemu-system-x86-13150 [000] d..2 185370.441836: kvm_entry: vcpu 0

--
                        Gleb.