From owner-cvs-sys  Wed Dec  3 10:41:55 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA02324
          for cvs-sys-outgoing; Wed, 3 Dec 1997 10:41:55 -0800 (PST)
          (envelope-from owner-cvs-sys)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA02318;
          Wed, 3 Dec 1997 10:41:44 -0800 (PST)
          (envelope-from bde@zeta.org.au)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id FAA06698; Thu, 4 Dec 1997 05:38:10 +1100
Date: Thu, 4 Dec 1997 05:38:10 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199712031838.FAA06698@godzilla.zeta.org.au>
To: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG,
        sef@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/i386 identcpu.c machdep.c trap.c
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  Work around for the Intel Pentium F00F bug; this is Intel's recommended
>  workaround.  Note that this currently eats up two pages extra in the system;
>  this could be alleviated by aligning idt correctly, and then only dealing with
>  that (as opposed to the current method of allocated two pages and copying the
>  IDT table to that, and then setting that to be the IDT table).

No it couldn't, since a statically allocated IDT would be in the same 4MB
kernel pages as other data that needs to be written to.  Only about 1K for
statically allocated IDT could be saved easily.  Perhaps memory on either
side of the dynamically allocated IDT could be used for something.

Bruce