port-amd64/38480: x86 MTRR code makes invalid assumption of 8 variable MTRRs

[tls%NetBSD.ORG@localhost]

>Number:         38480
>Category:       port-amd64
>Synopsis:       x86 MTRR code makes invalid assumption of 8 variable MTRRs
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-amd64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 21 18:55:00 +0000 2008
>Originator:     tls%NetBSD.oRG@localhost
>Release:        NetBSD 4.99.58
>Organization:
        The NetBSD Foundation
>Environment:
System: NetBSD claw 4.99.58 NetBSD 4.99.58 (GENERIC) #1: Wed Apr 9 01:06:27 EDT 
2008 tls@claw:/usr/src/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:
        On a 2 socket SuperMicro X7DCL motherboard with two 4-core Xeon E5405
        processors, an amd64 INSTALL or GENERIC kernel panics in cpu_init
        for the boot processor.  This panic occurs because it receives a
        protection fault on the rdmsr() for the 8th variable MTRR for the
        CPU; this fault is not handled, though rdmsr() is defined to give
        a protection fault on any attempt to read an invalid MSR.

        It appears that on this CPU, as configured by this motherboard's
        BIOS, only 7 (not 8) variable MTRRs can be used by the OS (at
        least in 64 bit mode, possibly in 32 bit mode as well).  Supposedly
        this CPU family has a new (third?) MTRR type available which may,
        though the BIOS has been configured to disable it, be what is
        consuming the last variable MTRR.

        Evidently, though all prior Intel CPUs have actually had 8 MTRRs
        and some other manufacturers' CPU families are defined to have 8
        MTRRs (e.g. VIA/Centaur), Intel has never specified that 8 MTRRs
        will be present.  Rather, the OS is supposed to read the MTRR
        config register and mask the returned value with 0xff to obtain
        the number of variable-size MTRRs available for use.

        We can't do this because we use fixed size arrays to index the
        hardware MTRRs.  We need to adjust that.  Also, Linux code seems
        to believe that AMD CPUs have only 2 variable MTRRs but I think
        this actually applies only to K6 generation CPUs and is already
        handled by our i386 specific MTRR code.

        If I knew how to find the fixed MTRRs with an arbitrary number of
        variable MTRRs present, I think this would be a reasonably simple
        fix -- but I don't know that and don't have time to find the
        right Intel document today, thus this PR.  If someone else has
        it handy, I can provide access to my system which exhibits this
        problem for quick testing.

>How-To-Repeat:
        Try to boot a NetBSD/amd64 kernel on a SuperMicro X7DCL-3 or
        X7DCL-I motherboard with BIOS revision 1.0 and two Intel Xeon
        E5405 2.0GHz quad-core processors.  Boom.
>Fix:
        Removing options MTRR from the kernel config leaves the system
        working reasonably well, though I doubt it'd make X happy (I
        could care less about X).