From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1K1l6L-0000Ah-4p
	for qemu-devel@nongnu.org; Thu, 29 May 2008 12:35:41 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1K1l6J-0000AF-N5
	for qemu-devel@nongnu.org; Thu, 29 May 2008 12:35:40 -0400
Received: from [199.232.76.173] (port=54389 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1K1l6J-0000AA-H2
	for qemu-devel@nongnu.org; Thu, 29 May 2008 12:35:39 -0400
Received: from mail2.shareable.org ([80.68.89.115]:49617)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1K1l6J-0007nU-9F
	for qemu-devel@nongnu.org; Thu, 29 May 2008 12:35:39 -0400
Date: Thu, 29 May 2008 17:35:36 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] Re: KQEMU code organization
Message-ID: <20080529163536.GD21610@shareable.org>
References: <483C3D55.2000508@siemens.com> <483EA1AD.1010901@bellard.org>
	<20080529161322.GB21610@shareable.org>
	<200805291726.05398.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200805291726.05398.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.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://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

Paul Brook wrote:
> > I.e. kvm has two sub-modules for Intel VT and AMD SVM extensions (I
> > think that's their names).  It would be great if it hard a third KQEMU
> > sub-module (which would of course be the most complicated ;-)
> 
> I believe this is also a prerequisite for getting kqemu merged into
> maintream kernels, which IMHO is the only sane goal to have. Out of
> tree kernel modules simply aren't worth the effort.

I think there's utility in crossover between both of them too.

Sometimes it would be nice to have the speed and directness of kvm,
with the code scanning and replacement abilities of kqemu to block
particular instructions, pretend to be a specific CPU model, or
replace some hardware-accessing instruction sequences instead of
trapping and emulating them - without the guest seeing the replacement.

-- Jamie