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 1BL915-0004Xr-93
	for qemu-devel@nongnu.org; Tue, 04 May 2004 19:07:59 -0400
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30)
	id 1BL90X-0004OB-Ui
	for qemu-devel@nongnu.org; Tue, 04 May 2004 19:07:57 -0400
Received: from [199.232.41.8] (helo=mx20.gnu.org)
	by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.30) id 1BL8YL-0004Mf-7Y
	for qemu-devel@nongnu.org; Tue, 04 May 2004 18:38:17 -0400
Received: from [193.252.22.22] (helo=mwinf0901.wanadoo.fr)
	by mx20.gnu.org with esmtp (Exim 4.30) id 1BL8Wh-0007o9-Mx
	for qemu-devel@nongnu.org; Tue, 04 May 2004 18:36:35 -0400
Received: from bellard.org (ATuileries-112-1-1-148.w80-11.abo.wanadoo.fr
	[80.11.167.148])
	by mwinf0901.wanadoo.fr (SMTP Server) with ESMTP id B2D7118000E5
	for <qemu-devel@nongnu.org>; Wed,  5 May 2004 00:36:31 +0200 (CEST)
Message-ID: <40981B72.8030408@bellard.org>
Date: Wed, 05 May 2004 00:38:42 +0200
From: Fabrice Bellard <fabrice@bellard.org>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Windows 98 - hardware
References: <20040504024759.GB11099@jbrown.mylinuxbox.org>	<40970BCA.2030402@bellard.org>
	<1083681962.1484.2.camel@debian>
In-Reply-To: <1083681962.1484.2.camel@debian>
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

Lean Fuglsang wrote:
>>This is no longer right. qemu-fast will be able someday to run all OSes, 
>>but the price to pay will be less security (the emulated user space code 
>>will be able to write to the QEMU cpu code).
> 
> Okay, as long as I can put qemu into a seperate user that is fine. 
> And if Windows crashes, a virtual reboot is needed anyway.
> How much performance gain is the in using qemu-fast? Is it something I
> should look forward, or is it neglictible?

The performance gain will be important, especially for purely 
computational user tasks (close to native performances). The OS kernel 
itself will run at about the same speed as the 'standard' qemu.

To do better, a host kernel module will be needed, but I don't have the 
courage to do that yet.

> (I don't dare to ask for the timeframe ;)

Yes, it is better not to ask :-)

Fabrice.