From: Linus Torvalds <torvalds@linux-foundation.org>
To: "H. Peter Anvin" <hpa@zytor.com>, Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Mikael Petterson <mikpe@it.uu.se>,
Eric Biederman <ebiederm@xmission.com>
Subject: Re: [GIT PULL] x86 setup: correct booting on 486DX4
Date: Sun, 4 Nov 2007 15:59:17 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.0.999.0711041546510.15101@woody.linux-foundation.org> (raw)
In-Reply-To: <472E551E.2010507@zytor.com>
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
next prev parent reply other threads:[~2007-11-05 0:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200711042259.lA4Mxa0n025210@tazenda.hos.anvin.org>
2007-11-04 23:17 ` Linus Torvalds
2007-11-04 23:25 ` Linus Torvalds
2007-11-04 23:36 ` H. Peter Anvin
2007-11-04 23:26 ` H. Peter Anvin
2007-11-04 23:59 ` Linus Torvalds [this message]
2007-11-05 0:02 ` H. Peter Anvin
2007-11-05 0:12 ` H. Peter Anvin
2007-11-05 0:43 ` Eric W. Biederman
2007-11-05 1:10 ` Linus Torvalds
2007-11-04 23:27 ` Jeremy Fitzhardinge
2007-11-04 22:57 H. Peter Anvin
2007-11-05 0:14 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.0.999.0711041546510.15101@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@it.uu.se \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®