From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33)
	id 1C75dF-0005a4-EL
	for qemu-devel@nongnu.org; Tue, 14 Sep 2004 01:13:33 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33)
	id 1C75dD-0005Zk-K0
	for qemu-devel@nongnu.org; Tue, 14 Sep 2004 01:13:32 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.33) id 1C75dD-0005Za-Ik
	for qemu-devel@nongnu.org; Tue, 14 Sep 2004 01:13:31 -0400
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1C75XO-0002WV-5J
	for qemu-devel@nongnu.org; Tue, 14 Sep 2004 01:07:30 -0400
Received: from cisco.com (edinburgh.cisco.com [144.254.112.76])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8E57Q2P008107
	for <qemu-devel@nongnu.org>; Tue, 14 Sep 2004 07:07:26 +0200 (MEST)
Received: (from dfawcus@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id GAA20002
	for qemu-devel@nongnu.org; Tue, 14 Sep 2004 06:07:26 +0100 (BST)
Date: Tue, 14 Sep 2004 06:07:26 +0100
From: Derek Fawcus <dfawcus@cisco.com>
Subject: Re: [Qemu-devel] Host API escape
Message-ID: <20040914060726.A19722@edinburgh.cisco.com>
References: <E1C73HY-0002wj-9V@cell03.cell03.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <E1C73HY-0002wj-9V@cell03.cell03.com>;
	from digitale@digitaleric.net on Mon, Sep 13, 2004 at 10:43:00PM
	-0400
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

On Mon, Sep 13, 2004 at 10:43:00PM -0400, EricNorthup wrote:
> Ok, I think the things you can achieve with this mechanism are very
> exciting.  But please, *please* do not make another fork in x86!

Huh?  What do you mean by "another fork in x86"?  Or are you simply
referring to the fact that I've (re)defined a special instruction?

> What if you use the WRMSR instructions instead?  Then you can define
> MSRs which have certain behavior when written to / read from.  The whole
> point of MSRs is that they are model-specific, and that is the way to do
> this compatibly.

Hmm - a possibility.

I can look at changing to that once I've got the redir stuff working.
My initial concern was actually not to use / change any target visible
register,  so that I can inject this anywhere as a debug hook - where
it's currently quite useful.

DF