Merging 64 bit changes to -HEAD

[M. Warner Losh]

In message: <AANLkTikIMYAfntzNC60L7ZXZm2lCavtDhxCsmyiRrfw0 at mail.gmail.com>
            Neel Natu <neelnatu at gmail.com> writes:
: Hi,
: 
: On Tue, Jun 29, 2010 at 10:24 AM, M. Warner Losh <imp at bsdimp.com> wrote:
: > In message: <AANLkTilQIqF4FCfgLdVcKdcsAUVjCmr89Lu0TEXUFdYN at mail.gmail.com>
: >            "Jayachandran C." <c.jayachandran at gmail.com> writes:
: > : On Tue, Jun 29, 2010 at 2:28 AM, Luiz Otavio O Souza <lists.br at gmail.com> wrote:
: > : >> Thanks for the the update. Looks like pmap_map for kernel is failing,
: > : >> may be the new tlb_update code causes this.  Can you apply the
: > : >> attached patch and see if the problem still persists, it replaces the
: > : >> new tlb_update code with the older version.
: > : >>
: > : >> Obviously not a fix, but if we can narrow it down to this function,
: > : >> fixing will be easier.
: > : >>
: > : >> JC.
: > : >> <try.diff>
: > : >
: > : > JC,
: > : >
: > : > This fix the problem ! Thanks ! Now, at least, you know where to look :)
: > :
: > : The new tlb_update does not seem to update the tlb entry if the tlbp
: > : fails.  Here's a patch that should make the new function behave like
: > : the older one.  The patch is in attached file 'tlb-update.diff'.
: > :
: > : If that does not work, I'm not sure what the issue is.  You could also
: > : try try the nop-change.diff attached. It tries to switch the ssnop
: > : used for delay in the new code with 'nop' which was used by the old
: > : code.
: >
: > ssnop is a mips32r2/mips64r2 addition.  We likely need to get smarter
: > about the nop stuff, based on the CPU we configure.  I can't recall if
: > the Atheros is misp32 or mips32r2.  IIRC, the idt RC32434 is mips32,
: > as is the adm5120...
: >
: 
: It seems that ssnop should be identical to nop on non-superscalar processors.
: 
: Here is the snippet from vol2 of the mips64 architecture manual.
: 
: <snip>
: Format:
:                                    MIPS32
:             SSNOP
: Purpose:
: Break superscalar issue on a superscalar processor.
: Description:
: SSNOP is the assembly idiom used to denote superscalar no operation.
: The actual instruction is interpreted by the
: hardware as SLL r0, r0, 1.
: This instruction alters the instruction issue behavior on a
: superscalar processor by forcing the SSNOP instruction to
: single-issue. The processor must then end the current instruction
: issue between the instruction previous to the SSNOP
: and the SSNOP. The SSNOP then issues alone in the next issue slot.
: On a single-issue processor, this instruction is a NOP that takes an issue slot.
: </snip>
: 
: It may lead to less efficient code on multiple issue processors but
: replacing a nop with an ssnop should be always be safe, right?

You're right.  For processors that don't support ssnop, it is
identical to nop.  But a single ssnop may not be sufficient on all
processors.  But, as a practical matter, I think that 4 ssnops is the
same as 4 nops and sufficient for tlb hazards.

However, I was confusing ssnop with ehb (and jump variants).  ehb in
MIPS{32,64}R2 processors so that a single instruction will delay the
right amount to prevent any CP0 and other hazards.  I'd argue we
should use these instructions on R2 processors, since they are more
efficient than guessing the right number of nops.  Shorter too :)

Warner