Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 May 2003 08:50:21 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        Heiko Schaefer <hschaefer@fto.de>
Subject:   Re: 5.1-RELEASE TODO
Message-ID:  <3EC265BD.9B9FEFAC@mindspring.com>
References:  <XFMail.20030514102537.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On 14-May-2003 Terry Lambert wrote:
> > The DISABLE_PG_G, as I said in a previous posting, works around
> > an order of operation problem that needs to clear PG in %CR0
> > while it does it's thing, after which there's no problem with
> > enabling it.  See "IA-32 Intel Architecture Software Developer's
> > Manual, Volume 3: System Programming Guide for more details on
> > PG_G, the PG bit in %CR0, and the effect on TLB flushing; look
> > specifically at Section 10.9 of "Memory Cache Control", which is
> > entitled "Invalidating The TRanslation Lookaside Buffers".
> >
> > Specifically, writing %CR3 doesn't invalidate pages with PG_G
> > set on them if PG is set in %CR0.
> 
> Umm, Terry, that's the whole point of PGE.  You don't flush entries
> from the TLB that are "global", i.e. shared among all processes and
> don't change.  "Duh".  Basically your suggestion would be an
> expensive hack equivalent to DISABLE_PG_G.

No.  My suggestion would be to not load something into a global
page before some of the VM system mappings have been established.

Basically, there is some machdep.c code that's out of order.
Reordering it is hard, so I haven't done it yet.

In other words, the problem is that someone is enabling PG in
%CR0 way too early.

Read the first sentence again: "...works around an order of
operation problem...".

I think if you check the archives back to when I first started
recommending that both DISABLE_PSE and DISABLE_PG_G be used,
rather than just DISABLE_PSE, it comes down to the machdep.c
and locore.s reorganization, where I complained that the new
order of operation had problems.  This happened back before
the 5.0 DP1.  My suggestion then was "revert the changes";
barring that, someone is going to have to sit down and go
through the new code, like I went through the old code, and
understand where every byte of memory is coming from, and
how and when it gets into the memory map.  I personally
think this is probably the responsibility of the people who
changed the code and broke use of PG in the first place.


-- Terry



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EC265BD.9B9FEFAC>