From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VcPu5-0005H6-9o for qemu-devel@nongnu.org; Fri, 01 Nov 2013 21:21:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VcPtw-0007Yk-Td for qemu-devel@nongnu.org; Fri, 01 Nov 2013 21:21:29 -0400 Received: from mail-pa0-x232.google.com ([2607:f8b0:400e:c03::232]:63992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VcPtw-0007Xi-LM for qemu-devel@nongnu.org; Fri, 01 Nov 2013 21:21:20 -0400 Received: by mail-pa0-f50.google.com with SMTP id fb1so4761131pad.37 for ; Fri, 01 Nov 2013 18:21:18 -0700 (PDT) Sender: Richard Henderson Message-ID: <5274538A.2020006@twiddle.net> Date: Fri, 01 Nov 2013 18:21:14 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1383073495-5332-1-git-send-email-sebastian@macke.de> <1383073495-5332-6-git-send-email-sebastian@macke.de> <5270399A.1080907@macke.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 05/13] target-openrisc: Remove TLB flush on exception List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Sebastian Macke Cc: openrisc@openrisc.net, openrisc@lists.opencores.org, QEMU Developers , Ethan Hunt On 11/01/2013 11:58 AM, Peter Maydell wrote: >> > What is included in the tb hash? The virtual pc + physical page + the >> > tb_flags? Not the mmu_index? > You're right that the mmu_index is not included in the tb hash. > Does that mean that the CPU state which determines the > mmu_index needs to be in the tb_flags? I'm not sure and it's > not something I'd thought about before. Richard -- do you know? Normally the supervisor/hypervisor/whatever bit(s) is present in the tb_flags, and the mmu_index ought to be computed from that. That said, what normally happens is that we re-use cpu_mmu_index, which looks at env, which is technically wrong. But there's an assumption that the bits we're examining in env have been copied to tb_flags, so the data is actually in sync. r~