This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH v4] Fixups of Loongson2F
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: yanhua <yanh at lemote dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, Andreas Barth <aba at not dot so dot argh dot org>, Wu Zhangjin <wuzhangjin at gmail dot com>, zhangfx at lemote dot com, binutils at sourceware dot org, "Maciej W. Rozycki" <macro at linux-mips dot org>, admin at heihaier dot org, = <liushiwei at gmail dot com>, Zhang Le <r0bertz at gentoo dot org>
- Date: Sat, 27 Feb 2010 09:32:40 +0000
- Subject: Re: [PATCH v4] Fixups of Loongson2F
- References: <1258617915-9563-1-git-send-email-wuzhangjin@gmail.com> <20100224000937.GA21981@mails.so.argh.org> <4B865C31.3060501@redhat.com> <877hq1nksl.fsf@firetop.home> <4B8718BB.6020900@lemote.com>
yanhua <yanh@lemote.com> writes:
> I also think the documentation could be worded slightly better.
>
> +Eliminate instruction fetch from outside 256M region to work around the
> +Loongson2F @samp{jump} instructions.
>
> First, as a minor point, there's no instruction called "jump", so the
> @samp isn't really appropriate. More importantly, I think we should
> explicitly say that we're masking the address with 0xcffffffff because:
>
> 1. We're not actually preventing jumps outside the 256M region in some
> cases. E.g. jumps from TLB-mapped memory to directly-mapped memory
> could easily cross a 256M region even with the workaround. As I
> understand it, the unwritten (but natural) assumption is that kernel
> code should not jump from a TLB-mapped region. (And as the covering
> message said, only targets in the directly-mapped region matter,
> since TLBs shouldn't point to the physical memory in question.)
>
>
>
> The named '-mfix-loongson2f-jump' patch 'purpose is to prevent kernel or kernel
> modules to run into physical address 0x1fd0000~0x20000000. To simplify, we call
> it address outside 256M.
OK. The point I was trying to make though was that in some cases the
simplification isn't really accurate. On 64-bit targets, the patch
applies a mask of:
0xffffffffcfffffff
which doesn't prevent jumps outside the first 256M for xkphys addresses.
Zhang Fuxin's description was very good, as is yours here:
> The exact reason to do this is the io space exists here, And loongson
> 2f is a out-of-order executing processor. it will predict its path
> using history information when it come to jr, jalr and etc jump
> instructions. the history information is stored in BTB(branch target
> buffer). If with no this patch, some times, the cpu will try to fetch
> instruction from the above address(including io space). Some chips can
> not allow some io space acess beyond 64K. As we found, Cs5536 is a
> case. Other wise, it would cause the bus deadlock.
My concern is that too much has been lost when condensing this description
for the option documentation. How about changing:
Eliminate instruction fetch from outside 256M region to work around the
Loongson2F @samp{jump} instructions. Without it, under extreme cases, kernel
may crash. The issue has been solved in latest processor batches, but this fix
has no side effect to them.
to something like:
Mask the targets of all indirect jumps with @samp{0xffffffffcfffffff}
(that is, clear bits 29 and 28). This works around a situation in
which prefetching instructions from certain (invalid) physical
addresses could cause peripheral devices to deadlock.
The option stops any untaken jump from accidentally having a
@samp{kseg0}, @samp{kseg1} or @samp{xkphys} address in the affected
range. It is only needed for kernel code, and the errata only
affects early processor batches.
Corrections and word-smithing welcome!
Richard