Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

From	"Luis R. Rodriguez" <mcgrof@kernel.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code
Date	2016-03-30 02:40 +0200
Message-ID	<rickW-5N1-5@gated-at.bofh.it> (permalink)
References	(15 earlier) <ri8U2-39n-7@gated-at.bofh.it> <ria9s-4ad-21@gated-at.bofh.it> <ribfc-4ZF-9@gated-at.bofh.it> <ribyy-57X-13@gated-at.bofh.it> <ric1z-5En-3@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Tue, Mar 29, 2016 at 6:07 PM, Toshi Kani <toshi.kani@hpe.com> 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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code Toshi Kani <toshi.kani@hpe.com> - 2016-03-17 22:10 +0100
  Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-03-18 01:10 +0100
    Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code Toshi Kani <toshi.kani@hpe.com> - 2016-03-18 21:50 +0100
      Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-03-29 19:20 +0200
        Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code Toshi Kani <toshi.kani@hpe.com> - 2016-03-29 23:00 +0200
          Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-03-30 00:20 +0200
            Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code Toshi Kani <toshi.kani@hpe.com> - 2016-03-30 01:30 +0200
              Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-03-30 01:50 +0200
                Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code Toshi Kani <toshi.kani@hpe.com> - 2016-03-30 02:20 +0200
                Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-03-30 02:40 +0200

csiph-web