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

[Alexander Graf <agraf@suse.de>]

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