From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lc5lK-0002wV-4x for qemu-devel@nongnu.org; Tue, 24 Feb 2009 17:28:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lc5lJ-0002wI-6I for qemu-devel@nongnu.org; Tue, 24 Feb 2009 17:28:25 -0500 Received: from [199.232.76.173] (port=35715 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lc5lJ-0002wA-0g for qemu-devel@nongnu.org; Tue, 24 Feb 2009 17:28:25 -0500 Received: from mx20.gnu.org ([199.232.41.8]:13806) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lc5lI-0000OU-T4 for qemu-devel@nongnu.org; Tue, 24 Feb 2009 17:28:24 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lc5lF-0003Wk-5a for qemu-devel@nongnu.org; Tue, 24 Feb 2009 17:28:21 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [5849] Change MMIO callbacks to use offsets, not absolute addresses. Date: Tue, 24 Feb 2009 22:28:10 +0000 References: <200902240150.01619.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902242228.11210.paul@codesourcery.com> 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: Blue Swirl > > Bits of both. The TLB is tightly tied into the code generator. Once we > > get out of the first-level TLB lookup you've not got anywhere near enough > > information to be able to restore the CPU state. The only way to raise > > exceptions from within an IO handler is to sync CPU state before every > > memory access, and you really don't want to do that. This is why the > > existing unassigned access fault code is busted. > > But because of possible MMU and unaligned access faults we already > save PC and NPC (not in all cases). Handling of those faults works, > it's really needed for correct operation. For some faults PC/NPC save > is not necessary, the fault handler can calculate env->pc from host > PC. Why would the unassigned fault be different? I'm not sure how I can be any clearer. You either have to explicitly sync state (In teh case of SPARC this means saving PC and NPC), or you have to know about the fault in the low-level TLB processing code where you still have enough information to recover this information. Once you get into an IO handler you've no way of figuring out what the current CPU state is. The "not in all cases"/"some faults" you mention above is relatively rare instructions that may fault v.s. every memory access. Paul