From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53058)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <michael@walle.cc>) id 1VJ4VM-0006Dz-G1
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 12:40:06 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <michael@walle.cc>) id 1VJ4VF-0002bL-Sm
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 12:40:00 -0400
Received: from ssl.serverraum.org ([88.198.40.39]:49420)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <michael@walle.cc>) id 1VJ4VF-0002av-MW
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 12:39:53 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Date: Mon, 09 Sep 2013 18:39:49 +0200
From: Michael Walle <michael@walle.cc>
In-Reply-To: <1378285521-3230-1-git-send-email-afaerber@suse.de>
References: <1378285521-3230-1-git-send-email-afaerber@suse.de>
Message-ID: <c46ffb916a381e3d00ff0baf4778ec70@walle.cc>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel]
 =?utf-8?q?=5BRFC_qom-cpu_00/41=5D_QOM_CPUState=2C_pa?=
 =?utf-8?q?rt_13=3A_Emptying_CPU=5FCOMMON?=
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?UTF-8?Q?Andreas_F=C3=A4rber?= <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>, Peter Crosthwaite <peter.crosthwaite@xilinx.com>, Eduardo Habkost <ehabkost@redhat.com>, Riku Voipio <riku.voipio@iki.fi>, qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>, Blue Swirl <blauwirbel@gmail.com>, Li Guang <lig.fnst@cn.fujitsu.com>, Anthony Liguori <anthony@codemonkey.ws>, Igor Mammedov <imammedo@redhat.com>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, =?UTF-8?Q?Aur=C3=A9lien_Jarno?= <aurelien@aurel32.net>, Richard Henderson <rth@twiddle.net>


Hi,

Am 2013-09-04 11:04, schrieb Andreas F=C3=A4rber:
> On part 11, rth said for alpha that using CPUAlphaState in
> DisasContext was bad
> and that the relevant fields should be copied into DisasContext
> instead; a few
> targets still have an env field though and use it for register access=20
> and
> cpu_abort(), so I have just changed the type for now and call upon
> maintainers
> to review whether they want to do different changes.

Is there a preferred way to abort translation, if for example, the=20
translator finds an unknown opcode? I guess there should be some kind of=20
exception. But speaking of lm32, the real CPU, does not handle such a=20
situation, instead the behavior is just undefined. Also, the emulation=20
is mainly used for developing, not for hosting applications with=20
security in mind.

For the lm32 target, i would copy the required fields (only information=20
about the chosen cpu model) into the DisasContext as suggested. But then=20
i will still need the CPUState for the cpu_abort() call.

--=20
michael