From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KB2C5-00082Q-Pa for qemu-devel@nongnu.org; Tue, 24 Jun 2008 02:39:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KB2C4-000809-1I for qemu-devel@nongnu.org; Tue, 24 Jun 2008 02:39:57 -0400 Received: from [199.232.76.173] (port=36500 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KB2C3-0007zg-OU for qemu-devel@nongnu.org; Tue, 24 Jun 2008 02:39:55 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:47027) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KB2C3-0001VH-0u for qemu-devel@nongnu.org; Tue, 24 Jun 2008 02:39:55 -0400 Message-ID: <486096B2.1000407@web.de> Date: Tue, 24 Jun 2008 08:39:46 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <485FBE18.4090603@siemens.com> <20080623152348.GA16375@shareable.org> <485FC2BC.3040503@siemens.com> <20080623160047.GB16803@shareable.org> In-Reply-To: <20080623160047.GB16803@shareable.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEEC27E54A370528068890D7D" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [RESENT][PATCH 2/2] x86: Issue reset on triple faults Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kwolf@suse.de This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEEC27E54A370528068890D7D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Jamie Lokier wrote: > Jan Kiszka wrote: >>> It might be worth distinguishing between >>> triple-fault-used-by-guest-for-context-switch and triple faults which= >>> trigger a normal reset, and log only the latter. There's a >>> standardish way of distinguishing them, which the BIOS should check. >> You refer to setting some return address at some magic BIOS location? >=20 > Probably; I forget the details. There might be a CMOS byte, too. I checked some old documents: It's a combination of both. Some CMOS byte = (0x0f) signals the special reset, and a pointer in the BIOS memory=20 (0x40:0x67) describes the desired jump target. >=20 >> Isn't this something the BIOS should handle, not QEMU? >=20 > The BIOS should handle it, yes. But since it is standard behaviour, > it might be useful for QEMU to decide whether to _log_ the event as a > system reset based on that state. Yeah, meanwhile my brain seems to work again and actually read what you=20 mean. But I'm still not convinced that we should make a special case about=20 this in the QEMU core. The user is not forced to enable reset logging,=20 and maybe (s)he _does_ want to log also resets due to protected mode=20 exits - what then? Keep it simple, just log what actually happens if=20 logging is enabled. >=20 > Same for keyboard controller induced reset - that's also used for > context switching, in the same way. (Triple fault is only used > because it's faster.) >=20 > Same also for deciding whether -no-reboot should close down the QEMU > process. Now I think about it, that is the best reason to distinguish > them! >=20 >>> When helper(SVM_EXIT_SHUTDOWN, 0) is called, should it still also cal= l >>> qemu_system_reset_request()? >> helper_vmexit() is not expected to return (cpu_loop_exit). >=20 > Ok. It's not clear unless you know the code, which I don't. Just > wanted to check :-) Understanding the usage of setjmp/longjmp in QEMU is a key to grasp the=20 control flow - but it took me some time as well to realize this. :) Jan --------------enigEEC27E54A370528068890D7D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhglrcACgkQniDOoMHTA+mFsQCfYo1+xO3tJ1o4mmFwyUYnBdkq tVIAn13FMM+a5ina8wt11N2lWS8J4qZ2 =bZfq -----END PGP SIGNATURE----- --------------enigEEC27E54A370528068890D7D--