On Sun, 4 Nov 2007, H. Peter Anvin wrote:
>
> 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 still disagree.
I took out "Programming the 80386" just to check, and the documentation
very clearly states that when changing the CR0 bits (I quote):
"The program must execute a jump instruction immediately after
changing the value of the PE bit in order to flush the execution
pipeline of any instructions that may have been fetched in the
wrong mode. [...]"
In other words, not only is this documented since day 1, it makes total
sense, and they even said exactöy *why* that jump had to be done.
In fact, there's even a code example. It's page 624 in my copy of the
book, and yes, it has a short jump to flush things, followed by a long
jump. The code there looks like this:
; *****
; ** [4] Enter Protected Mode
; *****
SMSW AX
OR AX, PE
LMSW AX
JMP Flush
Flush:
JMP far ptr Start32
which is pretty damn conclusive. It's documented, it has examples, it
works. In other words, it's how you should do things.
And Linux always did it correctly. I don't understand why you disagree,
and why Jeremy says
"Having successfully broken the rules for a long time so far,
maybe we can get away with still cutting corners..."
when the fact is, we used to *not* cut corners, we used to *not* break the
rules, and what we used to do (a short jump immediately after setting PE)
was exactly what Intel always said you should do, and there is no question
what-so-ever about it.
So here's a suggestion:
- make the code do what it used to do. A regular jump to flush the
pipeline. Which is what Intel has always said should be done.
and I really don't see that there is any argument about this.
Linus
-
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]
