Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758143AbcC3Aee (ORCPT ); Tue, 29 Mar 2016 20:34:34 -0400 Received: from mail.kernel.org ([198.145.29.136]:41117 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751780AbcC3Aed (ORCPT ); Tue, 29 Mar 2016 20:34:33 -0400 MIME-Version: 1.0 In-Reply-To: <1459300060.6393.757.camel@hpe.com> References: <1457671546-13486-1-git-send-email-toshi.kani@hpe.com> <1457671546-13486-3-git-send-email-toshi.kani@hpe.com> <20160311092400.GB4347@pd.tnic> <1457722632.6393.130.camel@hpe.com> <20160311221747.GC25147@wotan.suse.de> <1457740571.6393.236.camel@hpe.com> <1457745396.6393.257.camel@hpe.com> <20160315001501.GF25147@wotan.suse.de> <1458085724.6393.425.camel@hpe.com> <20160315232916.GJ1990@wotan.suse.de> <1458251807.6393.474.camel@hpe.com> <1458336958.6393.544.camel@hpe.com> <1459288009.6393.699.camel@hpe.com> <1459296994.6393.748.camel@hpe.com> <1459300060.6393.757.camel@hpe.com> From: "Luis R. Rodriguez" Date: Tue, 29 Mar 2016 17:34:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code To: Toshi Kani Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Thomas Gleixner , Matt Fleming , Paul Gortmaker , Borislav Petkov , X86 ML , Paul Stewart , Ingo Molnar , Olof Johansson , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Juergen Gross , Jan Beulich , Stuart Hayes , Yinghai Lu , Prarit Bhargava Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1428 Lines: 33 On Tue, Mar 29, 2016 at 6:07 PM, Toshi Kani wrote: > On Tue, 2016-03-29 at 16:43 -0700, Luis R. Rodriguez wrote: >> I meant to ask about the case where the option the lets a user go in a >> muck with BIOS settings to disable MTRR e xists and the user disables >> MTRR. What would happen for fan control in such situations? I'd >> imagine such cases allow for a system to exist with proper fan >> control, and allow the kernel to boot without having to deal with the >> pesky MTRRs at all, while PAT lives on, no? > > You mean user disables MTRRs from BIOS setup menu? Yup! > I am not a BIOS guy, > but I do not think it offers such option when the code depends on it... Darn, I'm pretty sure I've seen such option before... can't seem to find such a toggle now. >> When you say regular memory you mean everything else we see as RAM? I >> was under the impression we'd only need MTRR for a special range of >> memory, and its up to implementation how they are used. If you can use >> MTRR to change the cache attribute for regular RAM and if this is >> actually a requirement if the default MTRR is UC then one way or >> another a BIOS seems to always require MTRR, either for UC setting for >> fan control or WB for regular RAM, is that right? > > Right, in one way or the other, MTRRs set WB to RAM and UC to MMIO. PAT is > overwritten by MTRRs, so RAM must be set to WB. I see... thanks.... Luis