From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K11Cc-0000Pe-N9 for qemu-devel@nongnu.org; Tue, 27 May 2008 11:35:06 -0400 Received: from [199.232.76.173] (port=42648 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K11Cc-0000PE-4P for qemu-devel@nongnu.org; Tue, 27 May 2008 11:35:06 -0400 Received: from mx1.polytechnique.org ([129.104.30.34]:52210) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K11Cb-000163-Ur for qemu-devel@nongnu.org; Tue, 27 May 2008 11:35:06 -0400 Received: from fbe1.dev.netgem.com (gw.netgem.com [195.68.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id D0B4E3316C for ; Tue, 27 May 2008 17:35:02 +0200 (CEST) Message-ID: <483C2A20.3010309@bellard.org> Date: Tue, 27 May 2008 17:34:56 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/6] use halted attribute for i386 too. References: <1211901505-30519-1-git-send-email-gcosta@redhat.com> <1211901505-30519-2-git-send-email-gcosta@redhat.com> <1211901505-30519-3-git-send-email-gcosta@redhat.com> <1211901505-30519-4-git-send-email-gcosta@redhat.com> In-Reply-To: <1211901505-30519-4-git-send-email-gcosta@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Glauber Costa wrote: > Unlike other architectures, i386 lacked a "halted" attribute, going > with a flag into hflags. By using the halted attribute, we can make > the code look like more other architectures, and simplify the code in > some instances. In this commit, we make the code for info_cpus simpler > in monitor.c Good for the I386 halted attribute, as it was a mistake to put in in the hflags. For the memory, hflags should contain only parts of the CPU state known at translation time and should be equal to tb->flags. Most CPUs (including x86 !) do not follow this sane rule. For cpu_info_ip, it would be simpler to return an uint64_t containing the PC. I don't think the sparc case with npc really matters. Fabrice.