From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=60469 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Pzzpt-0006Zm-4s
	for qemu-devel@nongnu.org; Wed, 16 Mar 2011 19:09:02 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <michael@walle.cc>) id 1PzzpP-0003sH-TC
	for qemu-devel@nongnu.org; Wed, 16 Mar 2011 19:08:32 -0400
Received: from mail.serverraum.org ([78.47.150.89]:58049)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <michael@walle.cc>) id 1PzzpP-0003ru-HK
	for qemu-devel@nongnu.org; Wed, 16 Mar 2011 19:08:31 -0400
From: Michael Walle <michael@walle.cc>
Subject: Re: [Qemu-devel] [PATCH 02/17] lm32: translation routines
Date: Thu, 17 Mar 2011 00:08:32 +0100
References: <1297379530-23487-1-git-send-email-michael@walle.cc>
	<201102172351.10938.michael@walle.cc>
	<87F6573B-BB9C-4A86-9B2E-C84948C77716@suse.de>
In-Reply-To: <87F6573B-BB9C-4A86-9B2E-C84948C77716@suse.de>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201103170008.32661.michael@walle.cc>
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.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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: Blue Swirl <blauwirbel@gmail.com>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, qemu-devel@nongnu.org, Richard Henderson <rth@twiddle.net>

Am Freitag 11 M=E4rz 2011, 06:57:18 schrieben Sie:
> On 17.02.2011, at 23:51, Michael Walle wrote:
> > Am Samstag 12 Februar 2011, 07:49:52 schrieb Blue Swirl:
> >>> That said, IMHO the best handling of unknown opcodes would be to kill
> >>> the VM.
> >>=20
> >> In this case it should be OK. Alternatively the VM could be halted, so
> >> that instead of restarting QEMU, only system_reset needs to be issued.
> >> This may be more useful for developers, since for example registers
> >> and memory can be examined after the error.
> >=20
> > Good idea! May I call vm_stop() in a tcg helper? Like in the following
> > example:
> >=20
> > void helper_vm_stop(uint32_t msg_id)
> > {
> >=20
> >    if (qemu_log_enabled()) {
> >   =20
> >        qemu_log("VM stopped: %s", err_msg_str[msg_id]);
> >   =20
> >    } else {
> >   =20
> >        fprintf(stderr, "VM stopped: %s", err_msg_str[msg_id]);
> >   =20
> >    }
> >=20
> > #ifndef CONFIG_USER_ONLY
> >=20
> >    vm_stop(0);
> >=20
> > #endif
> >=20
> >    env->exception_index =3D EXCP_HALTED;
> >    cpu_loop_exit();
> >=20
> > }
> >=20
> > If not, what is the proper way to stop/pause the VM from within the
> > executed code?
>=20
> Since I haven't seen any reply yet: Can't you just do the same as hlt and
> disable interrupts?
This won't set the VM stopped property, eg. 'info status' will still report=
=20
the VM status as running.

And the timer would still be running, wouldn't it?

=2D-=20
Michael