From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0F4e-0004B3-10 for qemu-devel@nongnu.org; Fri, 09 Apr 2010 10:20:44 -0400 Received: from [140.186.70.92] (port=46416 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0F4c-0004Ad-JU for qemu-devel@nongnu.org; Fri, 09 Apr 2010 10:20:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0F4Y-0006KP-R9 for qemu-devel@nongnu.org; Fri, 09 Apr 2010 10:20:42 -0400 Received: from 78-86-195-86.zone2.bethere.co.uk ([78.86.195.86]:40753 helo=sentinel1.shatteredsilicon.net) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0F4Y-0006K1-LR for qemu-devel@nongnu.org; Fri, 09 Apr 2010 10:20:38 -0400 Received: from ariia.shatteredsilicon.net (ariia.shatteredsilicon.net [10.2.3.1]) by sentinel1.shatteredsilicon.net (Postfix) with ESMTP id 09B4FF8876 for ; Fri, 9 Apr 2010 14:44:01 +0100 (BST) Message-ID: <4BBF2F61.7070201@bobich.net> Date: Fri, 09 Apr 2010 14:45:05 +0100 From: Gordan Bobic MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] 64-bit Guest With kqemu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, Has the issue with running 64-bit guests on 64-bit hosts with kqemu ever been resolved? I have seen numerous bug reports relating to the error kqemu: aborting: Unexpected exception 0x0d in monitor space when running 64-bit guests. I haven't seen any patches to resolve the problem, though, and the error reports go back a few years, and to kqemu 1.3. I am using kqemu 1.4 and that still suffers from it. This is particularly frustrating because it _almost_ works. The 64-bit Linux kernel loads, and the VM dies shortly after starting init, first at udev startup, or if that is disabled, a little later on. Is there a fix for this issue available? 32-bit guests, of course, run perfectly fine. I know that kqemu support is being dropped with qemu 0.12.x, but it is still a very useful tool for machines without hardware VT support (e.g. Atoms), hence why I am still actively using it. The only alternative for VT-less hardware and remotely reasonable performance is vmware, and that has several un-disablable "features" that make it unworkable for a lot of my use-cases. TIA. Gordan