Re: openbsd system_powerdown: "KVM internal error. Suberror: 1"

[Avi Kivity <avi@redhat.com>]

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