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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
