From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: openbsd system_powerdown: "KVM internal error. Suberror: 1" Date: Mon, 21 Mar 2011 12:28:56 +0200 Message-ID: <4D872868.2010005@redhat.com> References: <4D7A0D58.6030802@msgid.tls.msk.ru> <20110316194440.GA23920@amt.cnet> <4D8118E7.5090609@msgid.tls.msk.ru> <20110317175233.GB18897@amt.cnet> <4D826CA5.1030607@msgid.tls.msk.ru> <4D871DC4.7000704@redhat.com> <4D87248F.3020106@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , KVM list , Gleb Natapov To: Michael Tokarev Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55911 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752521Ab1CUK3C (ORCPT ); Mon, 21 Mar 2011 06:29:02 -0400 In-Reply-To: <4D87248F.3020106@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: On 03/21/2011 12:12 PM, Michael Tokarev wrote: > 21.03.2011 12:43, Avi Kivity wrote: > > On 03/17/2011 10:18 PM, Michael Tokarev wrote: > > [] > >> 47965.428791: kvm_exit: reason npf rip 0xd020203a > >> 47965.428791: kvm_page_fault: address bfff0 error_code 4 > >> 47965.428792: kvm_emulate_insn: 0:d020203a: 5a (prot32) > >> 47965.428792: kvm_mmio: mmio unsatisfied-read len 4 gpa 0xbfff0 val 0x0 > >> 47965.428793: kvm_mmio: mmio read len 4 gpa 0xbfff0 val 0xb100 > >> 47965.428794: kvm_entry: vcpu 0 > >> 47965.428795: kvm_exit: reason npf rip 0xd020203b > >> 47965.428795: kvm_page_fault: address bfff4 error_code 4 > >> 47965.428795: kvm_emulate_insn: 0:d020203b: 59 (prot32) > >> 47965.428796: kvm_mmio: mmio unsatisfied-read len 4 gpa 0xbfff4 val 0x0 > >> 47965.428797: kvm_mmio: mmio read len 4 gpa 0xbfff4 val 0x0 > >> 47965.428797: kvm_entry: vcpu 0 > >> 47965.428798: kvm_exit: reason npf rip 0xd020203c > >> 47965.428798: kvm_page_fault: address bfff8 error_code 4 > >> 47965.428799: kvm_emulate_insn: 0:d020203c: 58 (prot32) > > > > That's a POP instruction. So openbsd mapped the stack into the > > framebuffer, and kvm has to emulate everything. > > > > Please post a complete binary trace from bootup until the > > host_state_reload issue appears. > > http://95.84.243.119:8000/tmp/kvm-obsd/ -- that's the whole > thing. > > There, trace.dat.gz and trace.txt.gz are the complete traces > from trace-cmd from the beginning to the login prompt. > > I don't think it's easy to catch the place when host_state_reloads > starts increasing - it happens during boot before userspace takes > control, while in kernel (during this time the text on the screen - > bootup progress - in on a strange background color). The difficulty > is because during that time there are lots of other activity on > kvm side - number of exits and emulations for example. > > Also, obsd4.8-32bit.qcow2.xz is the disk image of openbsd install > which I used for all these tests - it's 112 Mb compressed, about > 600Mb uncompressed, 2Gb virtual size. This is here in order for > me to stop acting as a broken phone (but I can continue doing so > just fine - I just think it's a bit less productive this way :) > > I've shown this file to Gleb Natapov (Cc'd) before too (who tried > to debug the "insane amount of host_state_reload" issue. This is > a default openbsd install from their current installation cdrom, > so anyone can create their own disk image too, obviously. > > I run it just like "kvm -hda obsd4.8-32bit.qcow2 -snapshot -net none" > (and it can use rtl8139 NIC). Root password is "12", but there's no > need to login since all the problems happens before login. > > In order to trigger the error in $subject, wait till it's idle > (which happens right after "login:" prompt) and send > "system_powerdown" command (I use -monitor stdio) - in about > 5 seconds from there it'll error out. In order to catch this > error it's better to use kvm 0.12 (it works with current seabios > under freebsd since graphics mode isn't used) -- current 0.14 > behaves badly after "KVM internal error" (which needs to be > improved a bit too, I think) > > >> 47965.428799: kvm_mmio: mmio unsatisfied-read len 4 gpa 0xbfff8 val 0x0 > >> 47965.428801: kvm_mmio: mmio read len 4 gpa 0xbfff8 val 0x30 > >> 47965.428801: kvm_entry: vcpu 0 > >> 47965.428802: kvm_exit: reason vintr rip 0xd0202041 > >> 47965.428802: kvm_inj_virq: irq 81 > >> 47965.428802: kvm_inj_virq: irq 81 > >> 47965.428803: kvm_entry: vcpu 0 > >> 47965.428803: kvm_exit: reason npf rip 0xd0202041 > >> 47965.428804: kvm_page_fault: address bfffc error_code 6 > >> 47965.428804: kvm_emulate_insn: 0:d0202041: cf (prot32) > >> 47965.428805: kvm_emulate_insn: 0:d0202041: cf (prot32) failed > > > > We don't emulate IRET-with-mmio-stack. > > Note that the whole this story - two issues with OpenBSD - is > pure my "luck" - I don't use openbsd, never used it before, and > don't actually plan to use in a near future. We debugged an > unrelated problem (a bug in linux nfs server) and tried to > perform various interoperability tests (installing various > operating systems in kvm), and found out that OpenBSD behaves > somewhat.. unexpectedly in kvm. So I went on and performed > a few tests locally (installing OpenBSD for the first time > ever), which resulted in 2 my "bugreports". > > I'm not sure how important OpenBSD support for kvm is, and if > it's something which better be done in OpenBSD itself instead > of kvm. There's no such thing as OpenBSD support. We emulate a PC, and OpenBSD runs on a PC. If it doesn't work well, there's a bug in one or the other. It's true that the bug has relatively low priority if it's just OpenBSD that triggers it. > (This all is not to say I wont help resolving these issues - > quite the opposite, I'm willing to help, but I think my help > in a form of broken phone isn't of much value :) Yes, it's better if we can reproduce this, and I understand from Gleb's message that we can. -- error compiling committee.c: too many arguments to function