From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1INwmL-0003zx-Rm
	for qemu-devel@nongnu.org; Wed, 22 Aug 2007 16:26:14 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1INwmK-0003yl-UM
	for qemu-devel@nongnu.org; Wed, 22 Aug 2007 16:26:13 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1INwmK-0003yT-R1
	for qemu-devel@nongnu.org; Wed, 22 Aug 2007 16:26:12 -0400
Received: from mx2.suse.de ([195.135.220.15])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <agraf@suse.de>) id 1INwmK-0005w8-M0
	for qemu-devel@nongnu.org; Wed, 22 Aug 2007 16:26:12 -0400
Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 66F84218CA
	for <qemu-devel@nongnu.org>; Wed, 22 Aug 2007 22:26:10 +0200 (CEST)
Message-ID: <46CC9BF7.6040002@suse.de>
Date: Wed, 22 Aug 2007 22:26:31 +0200
From: Alexander Graf <agraf@suse.de>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH][RFC] SVM support
References: <46CC956B.2060002@suse.de>
	<f43fc5580708221319k325a0e36kbd615864c528eac2@mail.gmail.com>
In-Reply-To: <f43fc5580708221319k325a0e36kbd615864c528eac2@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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: qemu-devel@nongnu.org

Blue Swirl wrote:
> On 8/22/07, Alexander Graf <agraf@suse.de> wrote:
>   
>> - All interceptions (well, maybe I did oversee one or two)
>>     
>
> Nice work! For better performance, you should do the op.c checks
> statically at translation time (if possible).
>
>
>   
Thanks. I thought about that first as well, but can't. The information
if an intercept should occur is defined in the VMCB, which is passed as
argument on VMRUN (so whenever one enters the VM). This means that the
very same TB can be executed with completely different intercepts, which
means I have to fall back to runtime detection in op.c.

I thought about moving some functionality from helper.c to op.c.
Does that improve anything?