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~
