From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeC4d-0001UZ-Rk for qemu-devel@nongnu.org; Wed, 06 Nov 2013 17:59:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VeC4V-00038q-8S for qemu-devel@nongnu.org; Wed, 06 Nov 2013 17:59:43 -0500 Received: from mail-we0-x22e.google.com ([2a00:1450:400c:c03::22e]:34309) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeC4V-000379-0w for qemu-devel@nongnu.org; Wed, 06 Nov 2013 17:59:35 -0500 Received: by mail-we0-f174.google.com with SMTP id p61so183327wes.33 for ; Wed, 06 Nov 2013 14:59:33 -0800 (PST) Date: Wed, 6 Nov 2013 23:59:15 +0100 From: "Edgar E. Iglesias" Message-ID: <20131106225915.GA31594@smtp.vpn> References: <1383073495-5332-1-git-send-email-sebastian@macke.de> <1383073495-5332-6-git-send-email-sebastian@macke.de> <5270399A.1080907@macke.de> <5274538A.2020006@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5274538A.2020006@twiddle.net> Subject: Re: [Qemu-devel] [Openrisc] [PATCH 05/13] target-openrisc: Remove TLB flush on exception List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Sebastian Macke , Peter Maydell , Ethan Hunt , QEMU Developers , openrisc@openrisc.net, openrisc@lists.opencores.org On Fri, Nov 01, 2013 at 06:21:14PM -0700, Richard Henderson wrote: > 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. > That's right, I tripped over this with the microblaze port some years ago. It might be a good idea to add an --enable-debug enabled check that asserts the consistency of tb_flags and current mmu_index. Cheers, Edgar