From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 27459 invoked from network); 11 Dec 2020 14:32:42 -0000
Received: from ewsd.inri.net (107.191.116.128)
  by inbox.vuxu.org with ESMTPUTF8; 11 Dec 2020 14:32:42 -0000
Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Fri Dec 11 09:27:55 -0500 2020
Message-ID: <0EE47D607AC47ADDD13CB3D571814581@felloff.net>
Date: Fri, 11 Dec 2020 15:27:44 +0100
From: cinap_lenrek@felloff.net
To: 9front@9front.org
In-Reply-To: <59540567-ACE4-46A1-8B60-78B9BBF78187@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: extended open callback browser dependency controller 
Subject: Re: [9front] kernel crash in bhyve
Reply-To: 9front@9front.org
Precedence: bulk

> That makes sense.  The registers are 0 with the correct offset.

> ; for(r in 0x2ff 0x0fe) io -r -M $r
> 0x0
> 0x0


Yes, that explains it. This also means MTRR's are disabled in MTRRdeftype register.

The processor manual says:

E (MTRRs enabled) flag, bit 11:
MTRRs are enabled when set; all MTRRs are disabled when clear,
and the UC memory type is applied to all of physical memory.

However, the MTRRCap is also 0, basically meaning we have 0
variable length MTRR's and no fixed MTRR support.

I can use that setting so conclude that MTRR's are not supported
instead of relying on CPUID and the sanity check in memory.c.

--
cinap