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 1AyABo-0007Bj-5q
	for qemu-devel@nongnu.org; Tue, 02 Mar 2004 08:44:04 -0500
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30)
	id 1AyAAk-0006YD-8w
	for qemu-devel@nongnu.org; Tue, 02 Mar 2004 08:43:31 -0500
Received: from [213.41.78.209] (helo=smtp-ft6.fr.colt.net)
	by monty-python.gnu.org with esmtp (Exim 4.30) id 1AyA9X-0005jm-3A
	for qemu-devel@nongnu.org; Tue, 02 Mar 2004 08:41:43 -0500
Received: from alcor.imaginet.fr (alcor.imaginet.fr [195.68.86.12])
	by smtp-ft6.fr.colt.net with ESMTP id i22DfdG03108
	for <qemu-devel@nongnu.org>; Tue, 2 Mar 2004 14:41:39 +0100
Received: from gw.netgem.com ([195.68.2.34]:64788 helo=bellard.org)
	by alcor.imaginet.fr with esmtp (Exim) id 1AyABb-0000VL-8x
	for <qemu-devel@nongnu.org>; Tue, 02 Mar 2004 14:43:51 +0100
Message-ID: <40448EFE.4000104@bellard.org>
Date: Tue, 02 Mar 2004 14:41:18 +0100
From: Fabrice Bellard <fabrice@bellard.org>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] qemu-fast - a better howto?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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


 > What about a better howto about qemu-fast (how to set up, etc.)

I will update the documentation for the next release. My idea is to 
split it between user documentation and technical documentation.

I will also make a fix for the compilation of qemu-fast for the LDT problem.

The current state of qemu-fast in CVS is that it can only launch patched 
OSes, but at near native speeds (no precise benchmarks yet).

The specific "roadmap" for qemu-fast is:

- native floating point support (qemu-fast still uses full emulation for 
floating point, which is slow).

- faster self modifying code support (qemu-fast is slower than qemu on 
16 bit code which heavily uses self modifying code).

- faster memory mapped device access (qemu-fast is slower than qemu for 
VGA emulation).

- huge memory support (qemu-fast can simulate up to 256 MB of RAM, but 
this limit will be increased to 4 GB, and then 64 GB).

Fabrice.