Module Name: src
Committed By: martin
Date: Tue Aug 29 12:47:29 UTC 2017
Modified Files:
src/sys/arch/evbmips/conf [netbsd-8]: std.loongson
src/sys/arch/mips/mips [netbsd-8]: mipsX_subr.S
src/usr.sbin/sysinst/arch/evbmips [netbsd-8]: md.h
Log Message:
Pull up following revision(s) (requested by maya in ticket #246):
sys/arch/evbmips/conf/std.loongson: revision 1.2
usr.sbin/sysinst/arch/evbmips/md.h: revision 1.2
sys/arch/mips/mips/mipsX_subr.S: revision 1.101
sys/arch/mips/mips/mipsX_subr.S: revision 1.102
sys/arch/mips/mips/mipsX_subr.S: revision 1.103
sys/arch/mips/mips/mipsX_subr.S: revision 1.104
In working around loongson errata clear BTB and RAS, same as
other operating systems.
15 Errata: Issue of Out-of-order in loongson (translated)
In loongson 2F, because of the branch prediction, sometimes the CPU
may fetch the instructions from some unexpected area (for example I/O
space). It is an invalid operation. There are two ways for the CPU to
choose the branch target. The first one is predicting the branch
target according to the branch target history. The second one is
calculating the branch target by the ALU. There are most 8
instructions in the instruction window at the same time in loongson2f
(Remember the loongson 2f is superscalar, right?). Hence, the
branch target of an indirect branch(such as jr) could be got(may be
predicted by the branch target history) earlier and the instrctions of
the branch target could be prefetched even if there are branch
instructions before it. As a result, it is possible to fetch the
instructions from I/O region( say out-of the physical address range of
[0- 0x100000]) in kernel model because of the instruction prefetch of
the branch target.
There are some suggestions to prevent prefetching instructions from
the I/O region in kernel mode.
(1) When switching from user model to kernel model, you should flush
the branch target history such as BTB and RAS.
(2) Doing some tricks to the indirect branch target to make sure that
the indirect branch target can not be in the I/O region.
Remove whitespace I just introduced
Build the loongson kernels with all the binutils loongson2f errata workarounds
>From Zhang Fuxin via <a rel="nofollow"
>href="https://sourceware.org/ml/binutils/2009-11/msg00387.html";>https://sourceware.org/ml/binutils/2009-11/msg00387.html</a>
- The NOP issue
"The nature of the erratum is deeply related to the microarchitecture of
Loongson-2. It uses roughly a 4-way superscalar dynamically scheduled core,
instructions are excuted as much as possible in parallel with technics like
branch prediction etc. We use a 8-entry internal branch prediction queue to
keep track of each predicted branches, if some branches are proved to be
wrongly predicted, all the instructions following it will be cancelled,together
with the resources used by them, including the registers used for renaming, and
the queue entry will be freeed. There is a bug that might cause a hang when the
queue is full(some resources might been leaked due to conflict branch entries),
the workaround is to reduce the possiblity of branch queue full by using
renaming registers(they are also limited, can prevent too many simutaneos
branches). In theory this is still not enough to fully eliminate possible
hangs, but the possiblity is extremely low now and hard to be hit in real
code."
- The JUMP instructions issue
"The Loongson-2 series processors have quite complex micro-architecture, it will
try to execute instructions from the predicated branch of coming instruction
stream before they are confirmed to be run, if the predication of branch
direction is proved wrong later, the instructions will be cancelled, but if the
instructions is a read from memory, the read action might not be cancelled(but
the changes to register will) to enable some prefetch. This will lead to some
problems when compining with some chipsets. E.g. the AMD CS5536 used in
Yeeloong/Fuloong will hang if it gets an address in the physical address range
of 0x100000-0x200000(might be more other ranges). Speculative reads can perform
read at any address in theory(due to wrong prediction of branch directions and
the use of branch target buffer), thus in very few occasions they might cause a
hard lock of the machine.
To prevent this, we need to prevent some addresses from entering branch
target buffers. A way to do this is that to modify all jump targets, e.g.,
calulations of t9
...
jalr t9 =>
calculations of t9
or t9, t9, 0x80000000; // to make sure t9 is in kseg0
jalr t9
Of course, we have to consider 64/32bit, and modules addresses etc.
This only need to be performed on kernel code, because only there we can have
accesses not translated/limited by TLB. For user code, it is impossible to
generate accesses to unwanted physical address. So it is safe.
Also, to prevent addresses generated by user mode code to be used by the
kernel, we add a few empty jumps to flush the BTB upon entrance to kernel."
evbmips can "boot root FFSv2"
It typically uses a non-NetBSD bootloader (PMON, u-boot...) and those
don't differentiate from v1 from v2 - both are unsupported and it requires
a separate boot partition.
Don't need the errata workaround on user return
It's reported that the MMU will block such invalid reads in userland,
and it's only needed on entry.
use meaningful name for errata hack, dedup
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.1.46.1 src/sys/arch/evbmips/conf/std.loongson
cvs rdiff -u -r1.100 -r1.100.2.1 src/sys/arch/mips/mips/mipsX_subr.S
cvs rdiff -u -r1.1 -r1.1.20.1 src/usr.sbin/sysinst/arch/evbmips/md.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
