lkml.org 
[lkml]   [2004]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Does Flushing the Queue after PG REALLY a Necessity?
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.

> 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 ?

regards,
Phil

-
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/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.424 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site