Linus Torvalds wrote:
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so
we really do need the far jump immediately afterwards.
Hmm. I'm not sure I agree with the commit message.
This is documented behaviour on i386 and i486: instruction decoding is
decoupled from execution, so things that change processor mode have to do
a jump to make sure that %cr0 changes take effect.
It's not an instruction-decoding issue at all (that's a 16- vs 32-bit
issue, which can only be changed by a ljmp). Apparently the 486DX4
mis-executes the load to segment register, which is an EU function in
that context. (And yes, it's sort-of-documented behaviour in the sense
that the documentation says "do things this way", but the Intel docs are
unfortunately full of "do things this way" which don't make sense and
occasionally are actively harmful, too.)
I'm not entirely sure that it needs to be a long-jump, btw. I think any
regular branch is sufficient. You obviously *do* need to make the long
jump later (to reload %cs in protected mode), but I'm not sure it's needed
in that place. I forget the exact rules (but they definitely were
documented).
That's exactly the issue here. The code without this patch deferred the
long jump until after the segment loads, this worked on all processors
except, apparently, the 486DX4. Hence, move the ljmp up to the earliest
possible location.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
