Re: Does Flushing the Queue after PG REALLY a Necessity?

From: Coywolf Qi Hunt
Date: Mon Feb 23 2004 - 21:38:00 EST


Philippe Elie wrote:

On Mon, 23 Feb 2004 at 18:27 +0000, Coywolf Qi Hunt wrote:


H. Peter Anvin wrote:


Anyone happen to know of any legitimate reason not to reload %cs in
head.S? I think the following would be a lot cleaner, as well as a
lot safer (the jump and indirect branch aren't guaranteed to have the
proper effects, although technically neither should be required due to
the %cr0 write):


jump is sufficent when setting PG and required with cpu where cr0 write
does not serialize.

The problem is there's two jumps in the kernel. Intel's manual only asks for "Execute a near JMP instruction".



Anyone happen to know of any legitimate reason to flush the prefetch
queue after enabling paging?

I've read the intel manual volume 3 thoroughly. It only says that after
entering protected mode, flushing is required, but never says
specifically about whether to do flushing after enabling paging.

Furthermore the intel example code enables protected mode and paging at
the same time. So does FreeBSD. There's really no more references to check.

From the cpu's internal view, flushing for PE is to flush the prefetch
queue as well as re-load the %cs, since the protected mode is just about
to begin. But no reason to flushing for PG, since linux maps the
addresses *identically*.

If no any reason, please remove the after paging flushing queue code,
two near jump.


See IA32 vol 3 7.4 and 18.27.3

Anyway this code is known to work on dozen of intel/non intel processor,
how can you know if changing this code will not break an obscure clone ?

Right, I also think removing the flush code is risky. Thanks very much, chapter 18 is what i was looking for. I recalled in an old intel booklet, named like something 386 system guide, says JMP after PG as well as PE. But I didn't have that book at hand and didn't find any e-doc.

However, in 18.27.3, "The sequence bounded by the MOV and JMP instructions should be identity" implies no JMP is also viable practically. But we needn't to be that pedantic.

If no any reason for the two jumps, the code should be fixed to remains only ONE near jump.


Coywolf


--
Coywolf Qi Hunt
Admin of http://GreatCN.org and http://LoveCN.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/