Messages in this thread | | | Date | Sun, 4 Nov 2007 16:15:21 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [PATCH] fix i486 boot failure due to stale %ds |
| |
On Sun, 4 Nov 2007, H. Peter Anvin wrote: > > Joy. Apparently the Intel documentation is actually self-inconsistent. > Section 9.9.1, page 9-17 does indeed have the "far jump or call" injunction, > whereas the sample code in section 9.10.1, page 9-27, line 180 does a near > jump!
See the older code. There's literally two different issues:
- flushing the pipeline. Using a regular short jump is not only sufficient, but is a good idea because the byte sequence has no dependency on any modes, so it is guaranteed to flush any pipeline without itself having any behavioural differences.
This part is a no-op for later CPU's: they simply won't care, since they serialize the pipeline on their own (and the have to, since a correctly predicted branch no longer flushes it anyway).
So this is purely a i386/i486 thing (and *maybe* Pentium, but definitely not PPro and later)
- setting up the proper protected mode bits in CS. This obviously changes the CS itself, and anything that depends on any shadow state in CS will need this to happen first. In practice, very few things really depend on the CS bits, of course.
Doing them back-to-back is obviously the best situation, and leaves the minimum footprint for any dubious undocumented behaviour. That said, while the whole thing with shadow segment table is strictly speaking probably "undocumented" behaviour, it's certainly a reality, and lots of code has depended on the fact that even though you haven't reloaded a segment, the segment continues to work across mode switches thanks to the shadow table.
So it's not like there's any real secret to what happens until the longjump has been executed: we continue running with the CS shadow table entry being in "real mode", and the effect of that tends to be minimal. But in theory, the CS table entry could affect how instructions actually act, even though in practice I don't think it really has any real effect outside of the actual segment access check (and certainly did not in the i386/i486 timeframe).
So I'd suggest having both jumps back-to-back, but realistically, the first regular short jump is actually the one that is more important. That's the one that really matters on i386/i486 class machines, and later CPU's will generally do the right thing even with _neither_ jump there.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |