From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W60lk-0001QD-HL for qemu-devel@nongnu.org; Wed, 22 Jan 2014 11:35:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W60lc-0002IF-4l for qemu-devel@nongnu.org; Wed, 22 Jan 2014 11:35:12 -0500 Received: from mail-qa0-x231.google.com ([2607:f8b0:400d:c00::231]:62285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W60lb-00025d-VU for qemu-devel@nongnu.org; Wed, 22 Jan 2014 11:35:04 -0500 Received: by mail-qa0-f49.google.com with SMTP id w8so698956qac.8 for ; Wed, 22 Jan 2014 08:35:00 -0800 (PST) Sender: Richard Henderson Message-ID: <52DFF330.8080905@twiddle.net> Date: Wed, 22 Jan 2014 08:34:56 -0800 From: Richard Henderson MIME-Version: 1.0 References: <5296A674.2080406@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] outlined TLB lookup on x86 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xin Tong Cc: QEMU Developers On 01/22/2014 07:28 AM, Xin Tong wrote: > Can you tell me whether ARM is the only architecture that requires > special treatment for increasing tlb size beyond 256 entries so that i > can whip up a patch to the QEMU mainline. The major constraint for the non-arm ports is CPU_TLB_ENTRY_SIZE + CPU_TLB_BITS < immediate bit size I.e. (CPU_TLB_SIZE - 1) << CPU_TLB_ENTRY_BITS is representable as an immediate within an AND instruction. MIPS has a 16-bit unsigned immediate, and as written would generate bad code for CPU_TLB_BITS > 11. I386 has a 32-bit signed immediate, and would generate bad code for CPU_TLB_BITS > 26. Though I can't imagine you want to make it that big. SPARC has a 13-bit signed immediate, But it's written with a routine which checks the size of the constant and loads it if necessary. Which is good, because that's clearly already happening for CPU_TLB_BITS > 7. AArch64, ia64, ppc, ppc64 all use fully capable extract-bit-field type insns and could handle any change you make. S390 is written using generic routines like sparc, so it won't fail with any change. It ought to be adjusted to use the extract-bit-field type insns that exist in the current generation of machines. The oldest generation of machine would have reduced performance with CPU_TLB_BITS > 11. ARM is also a case in which armv6t2 and later could be written with an extract-bit-field insn, but previous versions would need to use 2 insns to form the constant. But at least we'd be able to combine the shift and and insns. r~