From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V21to-0008MA-9z for qemu-devel@nongnu.org; Wed, 24 Jul 2013 12:26:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V21tm-0003Uw-PD for qemu-devel@nongnu.org; Wed, 24 Jul 2013 12:26:48 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37370 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V21tm-0003Uk-Fi for qemu-devel@nongnu.org; Wed, 24 Jul 2013 12:26:46 -0400 Message-ID: <51F00041.3010005@suse.de> Date: Wed, 24 Jul 2013 18:26:41 +0200 From: Alexander Graf MIME-Version: 1.0 References: <51AD8D88.70104@redhat.com> <20130604075107.GJ4725@redhat.com> <3B8B589E-4019-4AEE-A846-1A3F45A2EB4D@suse.de> <51EFEFB9.7020905@redhat.com> <20130724152125.GI16400@redhat.com> <51EFF342.3090106@suse.de> <20130724161742.GI6029@redhat.com> In-Reply-To: <20130724161742.GI6029@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] VM can not boot after commit 235e898 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Anthony Liguori , Jordan Justen , qemu-devel Developers , Dunrong Huang , Hannes Reinecke , Paolo Bonzini , Jordan Justen 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