From owner-freebsd-current  Wed Sep 11 12:19:08 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA23164
          for current-outgoing; Wed, 11 Sep 1996 12:19:08 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA23157
          for <current@FreeBSD.org>; Wed, 11 Sep 1996 12:19:02 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA08571; Thu, 12 Sep 1996 05:15:00 +1000
Date: Thu, 12 Sep 1996 05:15:00 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199609111915.FAA08571@godzilla.zeta.org.au>
To: dg@Root.COM, kato@eclogite.eps.nagoya-u.ac.jp
Subject: Re: patch for Cyrix/Ti 486SLC/DLC CPU bug
Cc: current@FreeBSD.org
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>CR2 might be modified by hardware interruption before it is read.  The
>contributor of the trap.c modification observed:
>
>   1: CR2 register equals to 0 when it is read in trap_pfault().
>   2: The core dump shows CR2 should not be 0.
>   3: He change trap gate into interrupt gate, CR2 shows correct
>      address.
>
>These observation imply the interruption breaks CR2.  This is the
>reason for the modification in machdep.c.

It would be better to read %cr2 early in _Xpage and disable interrupts
there:

_Xpage:
	pushl	$T_PAGEFLT
	pushal
	movl	%cr2,%eax
	sti
	/*
	 * Continue as before, except the copy of %cr2 must somehow be
	 * passed through trap() to the pagefault handler.
	 */

I've never liked filtering all exceptions through trap().  It would be
just as easy and a little faster to call trap_pfault() directly here
(easier except you have to repeat a few lines of book-keeping from
trap()).

Several other exceptions should use interrupt gates because interrupts
may be harmful:

Breakpoints and Debug Exceptions: it should be a debugger option (defaulting
to off) to allow interrupts.

NMI's: further NMI's are masked until the next `iret'.  Interrupts should
be masked so that the next `iret' is for the NMI handler and not for
an interrupt.

>> >   3)  The functions pmap_update_{1,2}pg don't use LMSW instruction
>> >       but call pmap_update in cpufunc.h (pmap.c).
>> 
>>    Is this because the Cyrix chip doesn't support selective TLB updates?
>
>Sorry, I lost Cyrix's data book and I couldn't check official
>information.  I think Cyrix chip supports selective TLB update, but it 
>may have bug and LMSW instruction fails in some cases.  I think this
>depends on the version of CPU because some Cyrix machines works without 
>pmap.c change.

pmap_update() actually stores to %cr3.  Thus has nothing to do with LMSW,
which loads from %cr0.  I guess the problem is in the non-386 case of
pmap_update_{1,2}pg().  The magic .byte's are a bad way of writing
`invlpg' (even gas understands this).

Bruce