From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EzkYH-0000ia-9q for qemu-devel@nongnu.org; Thu, 19 Jan 2006 19:54:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EzkYE-0000h7-H4 for qemu-devel@nongnu.org; Thu, 19 Jan 2006 19:54:51 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzkYD-0000go-Hw for qemu-devel@nongnu.org; Thu, 19 Jan 2006 19:54:49 -0500 Received: from [209.204.185.216] (helo=gate.bitblocks.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EzkcK-0006E8-UU for qemu-devel@nongnu.org; Thu, 19 Jan 2006 19:59:05 -0500 Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.4/8.13.1) with ESMTP id k0K0pger047019 for ; Thu, 19 Jan 2006 16:51:42 -0800 (PST) (envelope-from bakul@bitblocks.com) Message-Id: <200601200051.k0K0pger047019@gate.bitblocks.com> Date: Thu, 19 Jan 2006 16:51:42 -0800 From: Bakul Shah Subject: [Qemu-devel] A number of OSes do not work with kqemu Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org The three I am aware of are: openbsd, netbsd & plan9. They work fine with -no-kqemu flag. This is under freebsd but I believe the same thing happens under linux. The easiest test case may be plan 9 it seems to dies very early. Download the plan9 .iso from one of http://www.tip9ug.jp/mirror/plan9.iso.bz2 http://www.9grid.de/plan9/plan9.iso.bz2 Decompress, fire up qemu and boot from the .iso, giving qemu some hard disk image. It will ask whether you want to install plan9 or boot plan9 from from the CD. Choose the latter. It will die almost right away with an error message like this: user fault: addr=00000000 pc=00001020 addr not mapped (vpd=00000000) pc not mapped (vpd=00000000) panic: boot process died: sys: trap: fault read addr=0x0 pc=0x00001020 I captured a log with `log all' command to qemu monitor console and compared the two cases (with and without kqemu). There are differences in the CCS register like so: @@ -6489,7 +6489,7 @@ GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 -CCS=00000000 CCD=0000f000 CCO=LOGICB +CCS=00000044 CCD=0000f000 CCO=EFLAGS ---------------- IN: 0x000f08e0: add $0x4,%sp @@ -7818,7 +7818,7 @@ GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 -CCS=00000014 CCD=00000400 CCO=EFLAGS +CCS=00000000 CCD=00000400 CCO=INCW ---------------- IN: 0x000f9a53: mov $0x9fc0,%ax diff done after filtering out lines matching egrep pattern "Servicing hardware|kqemu" from both log outputs. This is about as far as I can get without delving into qemu and I certainly do not want to reverse engineer kqemu! -- bakul