From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: kvm.git next: KVM internal error. Suberror: 1 Date: Mon, 08 Feb 2010 13:45:01 +0100 Message-ID: <4B70074D.1010508@siemens.com> References: <4B6FFDE2.5050105@siemens.com> <4B6FFF86.4040309@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: kvm To: Avi Kivity Return-path: Received: from goliath.siemens.de ([192.35.17.28]:20519 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751366Ab0BHMpU (ORCPT ); Mon, 8 Feb 2010 07:45:20 -0500 In-Reply-To: <4B6FFF86.4040309@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > On 02/08/2010 02:04 PM, Jan Kiszka wrote: >> Avi, >> >> with 2c8232f over kvm-kmod and "qemu-system-x86_64 -m 256 vm-image.qcow2 -snapshot -serial stdio -s -smp 2" I just got this: >> >> > > What is vm-image.qcow2? > >> KVM internal error. Suberror: 1 >> rax 0000000000000000 rbx 0000000000006f08 rcx 0000000000000000 rdx 0000000000000052 >> rsi 0000000000000000 rdi 00000000000f4fd4 rsp 0000000000006ed8 rbp 00000000000f7280 >> r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 >> r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 >> rip 00000000f000ff53 rflags 00010016 >> > > ffffff53 is an 'iret'. But f000ff53 doesn't make sense. > >> cs 0008 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) >> ds 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) >> es 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) >> ss 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) >> fs 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) >> gs 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) >> tr 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) >> ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) >> gdt f7a20/37 >> idt f8aa0/0 >> cr0 11 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 >> emulation failure >> >> Before that run, I started the very same VM and shut it down via >> system_powerdown. This is reproducible! >> > > Not sure I understand. This is with -snapshot, so how can a previous > run have any effect? > >> Maybe it's the same issue that causes the #UD regression with >> -no-kvm-irqchip. > > I wasn't able to reproduce. > Looks like tried to outsource my own bugs: I was on queues/vcpu-state, ie. my state writeback rework, and I'm unable to reproduce over qemu-kvm master. Will do my homework. Still, the issue around -no-kvm-irqchip exists with master. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux