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

[Alexander Graf]

On 07/24/2013 06:17 PM, Gleb Natapov wrote:
> 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

It works just fine with older QEMU:

 qemu-system-x86-9448  [001] d..2 162748.223935: kvm_exit: reason 
IO_INSTRUCTION rip 0xc471 info 920040 0
 qemu-system-x86-9448  [001] ...1 162748.223936: kvm_pio: pio_write at 
0x92 size 1 count 1
 qemu-system-x86-9448  [001] ...1 162748.223936: kvm_userspace_exit: 
reason KVM_EXIT_IO (2)
 qemu-system-x86-9448  [001] d..2 162748.223939: kvm_entry: vcpu 0
 qemu-system-x86-9448  [001] d..2 162748.223940: kvm_exit: reason 
EXCEPTION_NMI rip 0xc473 info 0 80000b0d
 qemu-system-x86-9448  [001] ...1 162748.223942: kvm_emulate_insn: 
f0000:c473:2e 0f 01 1e e0 d3 (real)
 qemu-system-x86-9448  [001] d..2 162748.223945: kvm_entry: vcpu 0
 qemu-system-x86-9448  [001] d..2 162748.223946: kvm_exit: reason 
EXCEPTION_NMI rip 0xc479 info 0 80000b0d
 qemu-system-x86-9448  [001] ...1 162748.223947: kvm_emulate_insn: 
f0000:c479:2e 0f 01 16 a0 d3 (real)
 qemu-system-x86-9448  [001] d..2 162748.223948: kvm_entry: vcpu 0
 qemu-system-x86-9448  [001] d..2 162748.223948: kvm_exit: reason 
EXCEPTION_NMI rip 0xc47f info 0 80000b0d
 qemu-system-x86-9448  [001] ...1 162748.223950: kvm_emulate_insn: 
f0000:c47f:0f 20 c0 (real)
 qemu-system-x86-9448  [001] d..2 162748.223951: kvm_entry: vcpu 0
 qemu-system-x86-9448  [001] d..2 162748.223951: kvm_exit: reason 
EXCEPTION_NMI rip 0xc486 info 0 80000b0d
 qemu-system-x86-9448  [001] ...1 162748.223952: kvm_emulate_insn: 
f0000:c486:0f 22 c0 (real)
 qemu-system-x86-9448  [001] d..2 162748.223955: kvm_entry: vcpu 0
 qemu-system-x86-9448  [001] ...1 162748.223956: kvm_emulate_insn: 
f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
 qemu-system-x86-9448  [001] d..2 162748.223959: kvm_entry: vcpu 0
 qemu-system-x86-9448  [001] ...1 162748.223960: kvm_emulate_insn: 
0:fc491:b8 10 00 00 00 (prot32)
 qemu-system-x86-9448  [001] d..2 162748.223961: kvm_entry: vcpu 0
 qemu-system-x86-9448  [001] ...1 162748.223961: kvm_emulate_insn: 
0:fc496:8e d8 (prot32)
 qemu-system-x86-9448  [001] d..2 162748.223963: kvm_entry: vcpu 0
 qemu-system-x86-9448  [001] ...1 162748.223964: kvm_emulate_insn: 
0:fc498:8e c0 (prot32)
 qemu-system-x86-9448  [001] d..2 162748.223965: kvm_entry: vcpu 0
[...]

> before. Are you saying configuring BIOS memslot differently solves the
> problem?

Git bisect pointed to the commit mentioned in this email. The following 
patch also gets me a working guest again:

diff --git a/kvm-all.c b/kvm-all.c
index 4fb4ccb..deca9e5 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1455,7 +1455,7 @@ int kvm_init(void)
         s->irq_set_ioctl = KVM_IRQ_LINE_STATUS;
     }

-#ifdef KVM_CAP_READONLY_MEM
+#if 0 //def KVM_CAP_READONLY_MEM
     kvm_readonly_mem_allowed =
         (kvm_check_extension(s, KVM_CAP_READONLY_MEM) > 0);
 #endif


Alex