Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Apr 2008 23:21:58 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        nao@tom-yam.or.jp
Cc:        freebsd-mips@FreeBSD.org
Subject:   Re: minor fix for tlb manipulations
Message-ID:  <20080426.232158.1683324026.imp@bsdimp.com>
In-Reply-To: <2da2ec620804222103r7e90af37j2d36b0f0bc049abb@mail.gmail.com>
References:  <2da2ec620804222103r7e90af37j2d36b0f0bc049abb@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <2da2ec620804222103r7e90af37j2d36b0f0bc049abb@mail.gmail.com>
            "Naoki Hamada" <nao@tom-yam.or.jp> writes:
: I found a slight problem in tlb.S which tries to manipulate
: no-existing tlbs. The argument of Mips_TLBFlush() and mips_TBIAP() is
: the number of tlbs to deal with, but both functions process the same
: number of tlb pairs, so twice the number of actual tlbs.

I believe that the argument is the number of pairs to invalidate, at
least in the case of Mips_TLBFlush.  The number passed in is the
MMUSize field from CO_Config1, which indicates the number of pairs
that exist in the tlb.  True, each iteration of the loop invalidates a
pair of TLB entires, I think that the code is correct as it is.  The
MMUSize field returns the number of pairs, so I don't think any
biasing is needed.

The current Mips_TLBFlush function matches the InitTLB function given
in the MIPS32 Architecture for Programmers, Volume III.

: TLBWI entry of "MIPS32 Architecture For Programmers Volume II: The
: MIPS32 Instruction Set" states that "The operation is UNDEFINED if the
: contents of the Index register are greater than or equal to the number
: of TLB entries in the processor." It seems to do no harm to my system,
: but your mileage may vary.

Correct.  However, the count is the number of pairs, not the total
number.

Have I missed something in my reading the code and the mips32 specs?

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080426.232158.1683324026.imp>