From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IpVCj-0006DO-MT for qemu-devel@nongnu.org; Tue, 06 Nov 2007 15:39:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpVCh-0006DB-HS for qemu-devel@nongnu.org; Tue, 06 Nov 2007 15:39:20 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpVCh-0006D8-C5 for qemu-devel@nongnu.org; Tue, 06 Nov 2007 15:39:19 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IpVCg-0000Az-Rx for qemu-devel@nongnu.org; Tue, 06 Nov 2007 15:39:19 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] sparc32 boot mode flag fix Date: Tue, 6 Nov 2007 20:39:10 +0000 References: <472FD561.7020006@earthlink.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711062039.12196.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 > > This patch also removes the MMU flags from being saved in the > > translation block code as a result of an off line discussion with Paul > > Brook. > > I'd like to hear the reasoning behind that. The TBs generated while in > boot mode and MMU disabled may contain translations generated from > virtual to physical mappings that do not exist when the mode is > changed. Boot mode and MMU disable are not used after boot and these > bits don't affect translation, so those bits may be less important and > not worth the few bits in TB flags. It think you're confusing the TB cache with the TLB. Each TB is already indexed by both physical and virtual address (explicitly in tb_find_slow, and implicitly in tb_find_fast because a tlb flush clears env->tb_jmp_cache). IIUC enabling/disabling boot mode is no different to and other VM change. If the virtual->physical mapping happens to be the same then it's perfectly ok to reuse the TB. The TLB is already flushed whenever the MMU mode is changes. There is no need to invalidate the TB. Paul