From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K11z4-00051U-2H for qemu-devel@nongnu.org; Tue, 27 May 2008 12:25:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K11z2-00050T-Mz for qemu-devel@nongnu.org; Tue, 27 May 2008 12:25:09 -0400 Received: from [199.232.76.173] (port=60533 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K11z2-00050M-4N for qemu-devel@nongnu.org; Tue, 27 May 2008 12:25:08 -0400 Received: from wf-out-1314.google.com ([209.85.200.169]:43024) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K11z2-000367-A5 for qemu-devel@nongnu.org; Tue, 27 May 2008 12:25:08 -0400 Received: by wf-out-1314.google.com with SMTP id 27so2180591wfd.4 for ; Tue, 27 May 2008 09:25:06 -0700 (PDT) Message-ID: <5d6222a80805270925t4fea901co91a0464e4e73d362@mail.gmail.com> Date: Tue, 27 May 2008 13:25:05 -0300 From: "Glauber Costa" Subject: Re: [Qemu-devel] [PATCH 3/6] use halted attribute for i386 too. In-Reply-To: <483C2A20.3010309@bellard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <483C2A20.3010309@bellard.org> 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 On Tue, May 27, 2008 at 12:34 PM, Fabrice Bellard wrote: > 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. What about HF_GIF_MASK? It looks like another case of something that is mistakenly put into hflags. What do you say? > 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. > > > > -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."