From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toshi Kani Subject: Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code Date: Tue, 29 Mar 2016 19:07:40 -0600 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: "Luis R. Rodriguez" 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 List-Id: xen-devel@lists.xenproject.org On Tue, 2016-03-29 at 16:43 -0700, Luis R. Rodriguez wrote: > On Tue, Mar 29, 2016 at 5:16 PM, Toshi Kani wrot= e: > > On Tue, 2016-03-29 at 15:12 -0700, Luis R. Rodriguez wrote: > > > On Tue, Mar 29, 2016 at 2:46 PM, Toshi Kani > > > wrote: > > > > On Tue, 2016-03-29 at 10:14 -0700, Luis R. Rodriguez wrote: > > > > > On Fri, Mar 18, 2016 at 2:35 PM, Toshi Kani > > > > > wrote: > > =C2=A0: > > > > >=20 > > > > > Do we really need UC for the fan? > > > >=20 > > > > When you say "we", are you referring Xen guests?=C2=A0=C2=A0Xen= guests do not > > > > need to control the fan, so they do not need UC set in MTRRs. > > > >=20 > > > > In general, yes, MMIO registers need UC when they need to be > > > > accessed. > > >=20 > > > Curious, what does a BIOS do for fan control when MTRRs are disab= led? > >=20 > > You mean, when the kernel modified the MTRR setup and disabled them= =2E >=20 > Nope, but the below is good to know! >=20 > 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? =C2=A0I am not a BIO= S guy, but I do not think it offers such option when the code depends on it... > > BIOS would assume the original setup and still access the > > registers.=C2=A0=C2=A0This may lead to undefined behavior and may r= esult in a > > system crash. > >=20 > > > Also what if a BIOS just set MSR_MTRRdefType to uncachable only ? > >=20 > > Many BIOSes actually set the default type to UC. >=20 > Thanks, I asked as I saw my BIOS uses write-back by default. Good to > know there are different strategies. >=20 > > MTRRs then cover regular memory with WB. >=20 > 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 us= e > 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 fo= r > 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. =C2= =A0PAT is overwritten by MTRRs, so RAM must be set to WB. Thanks, -Toshi