Re: [PATCH v4] Fixups of Loongson2F

[Richard Sandiford <rdsandiford at googlemail dot 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