From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K11lH-0004TZ-A6 for qemu-devel@nongnu.org; Tue, 27 May 2008 12:10:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K11lF-0004Sr-Hz for qemu-devel@nongnu.org; Tue, 27 May 2008 12:10:54 -0400 Received: from [199.232.76.173] (port=57293 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K11lF-0004Sk-Dz for qemu-devel@nongnu.org; Tue, 27 May 2008 12:10:53 -0400 Received: from wf-out-1314.google.com ([209.85.200.171]:23190) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K11lF-0008Nh-C4 for qemu-devel@nongnu.org; Tue, 27 May 2008 12:10:53 -0400 Received: by wf-out-1314.google.com with SMTP id 27so2175652wfd.4 for ; Tue, 27 May 2008 09:10:52 -0700 (PDT) Message-ID: Date: Tue, 27 May 2008 19:10:51 +0300 From: "Blue Swirl" 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=UTF-8 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 5/27/08, 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. > > 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. It's not very likely that the NPC would be different for some value of PC when halted, but it's still nice.