From owner-freebsd-current@FreeBSD.ORG Wed May 14 08:51:41 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1684F37B401; Wed, 14 May 2003 08:51:40 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id B660743FAF; Wed, 14 May 2003 08:51:37 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0095.cvx21-bradley.dialup.earthlink.net ([209.179.192.95] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19FyXY-0004RE-00; Wed, 14 May 2003 08:51:37 -0700 Message-ID: <3EC265BD.9B9FEFAC@mindspring.com> Date: Wed, 14 May 2003 08:50:21 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ebfd88bf53c4128c09517b67bbd2d44e667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c cc: Robert Watson cc: re@FreeBSD.org cc: current@FreeBSD.org cc: Heiko Schaefer Subject: Re: 5.1-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 15:51:41 -0000 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