From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoarq-0007nu-6A for qemu-devel@nongnu.org; Fri, 08 Apr 2016 14:10:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoarm-0001oo-5b for qemu-devel@nongnu.org; Fri, 08 Apr 2016 14:10:50 -0400 Received: from mail-qg0-x22b.google.com ([2607:f8b0:400d:c04::22b]:34494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoarm-0001og-0F for qemu-devel@nongnu.org; Fri, 08 Apr 2016 14:10:46 -0400 Received: by mail-qg0-x22b.google.com with SMTP id c6so97031392qga.1 for ; Fri, 08 Apr 2016 11:10:45 -0700 (PDT) Sender: Richard Henderson References: <57029630.3070300@twiddle.net> <5702AACF.90306@twiddle.net> <1460136006.50712.3.camel@TomH-Z-Workstation> From: Richard Henderson Message-ID: <5707F422.1090100@twiddle.net> Date: Fri, 8 Apr 2016 11:10:42 -0700 MIME-Version: 1.0 In-Reply-To: <1460136006.50712.3.camel@TomH-Z-Workstation> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] best way to implement emulation of AArch64 tagged addresses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tom Hanson Cc: Peter Maydell , QEMU Developers On 04/08/2016 10:20 AM, Tom Hanson wrote: > Is it an option to mask off the tag bits in all cases? Is there any case > it which those bits are valid address bits? It's not impossible to mask off bits in the address -- we do that for running 32-bit on 64-bit all of the time. It's all a question of how well the average program will perform, I suppose. For instance. Are there more tagged addresses than non-tagged addresses? If we mask off bits, that will affect *every* memory operation. If tagged addresses are rare, then that is a waste. If tagged addresses are common, however, then we may well spend too much time ping-ponging in the TLB. The fastest method I can think of to ignore high order bits is to shift the address comparator left. The TLB comparator would be stored pre-shifted, so this would add only one insn on the fast path. Or perhaps zero in the case of an arm/aarch64 host, where the compare insn itself can perform the shift. Of course, a double-word shift would be completely out of the question when doing 64-bit on 32-bit emulation. But we don't need that -- just shift the high part of the address left to discard bits, leaving a funny looking hole in the middle of the comparator. This is simple enough that it should be relatively easy to patch up all of the tcg backends to match, if we decide to go with it. r~