From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30)
	id 1B3mXP-0000cY-Hk
	for qemu-devel@nongnu.org; Wed, 17 Mar 2004 20:41:35 -0500
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30)
	id 1B3mWm-0000W9-Pp
	for qemu-devel@nongnu.org; Wed, 17 Mar 2004 20:41:28 -0500
Received: from [193.170.194.10] (helo=zero.aec.at)
	by monty-python.gnu.org with esmtp (Exim 4.30) id 1B3mWm-0000P3-4x
	for qemu-devel@nongnu.org; Wed, 17 Mar 2004 20:40:56 -0500
References: <200403181832.59188.nick@mccomputing.co.uk>
	<4058BFD6.1030200@bellard.org>
From: Andi Kleen <ak@muc.de>
Date: Thu, 18 Mar 2004 02:40:16 +0100
In-Reply-To: <4058BFD6.1030200@bellard.org> (Fabrice Bellard's message of
	"Wed, 17 Mar 2004 22:15:02 +0100")
Message-ID: <m3smg7exvj.fsf@averell.firstfloor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Qemu-devel] Re: x86-64 port
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://mail.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://mail.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Fabrice Bellard <fabrice@bellard.org> writes:

> Nick Snellock wrote:
>> Is anyone working on an x86-64 port?
>
> Not me :-) An x86-64 host port would be very interesting because the
> 64 bit host MMU could be used to remap the whole emulated 4GB address
> space.

I tried to run it recently in 32bit emulation on the 64bit kernel,
but it just produced a lot of segfaults. Even when I forced the
address room to 3GB. Most likely it triggers bugs in the 32bit emulation
layer. I wasn't able to look into it yet.

> I think that there is also a lot of potential for a "code-copy" mode
> converting x86-32 to x86-64 code (look at what I did for . Along with
> the 4GB space remapping, it would give close to native performances
> without requiring any potentially unsafe kernel module (unlike the
> popular virtualizers).

Yes, and you may even get better code in the result (you have 16 registers
to play with instead of 8) 

There is one problem however: currently there are a few system calls
that know if they are executing in 32bit or 64bit and act accordingly.
You can call the 32bit int 0x80 system call handler from a 64bit process,
but you would probably run into smaller issues. This may need a few kernel
fixes. For example the environment and some other pointers are 64bit.
Should be all fixable though.

-Andi