From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Toshi Kani <toshi.kani@hpe.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Thomas Gleixner <tglx@linutronix.de>,
Matt Fleming <matt@codeblueprint.co.uk>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Borislav Petkov <bp@alien8.de>, X86 ML <x86@kernel.org>,
Paul Stewart <pstew@chromium.org>, Ingo Molnar <mingo@kernel.org>,
Olof Johansson <olof@lixom.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>, Juergen Gross <jgross@suse.com>,
Jan Beulich <JBeulich@suse.com>,
Stuart Hayes <stuart.w.hayes@gmail.com>,
Yinghai Lu <yinghai@kernel.org>,
Prarit Bhargava <prarit@redhat.com>
Subject: Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code
Date: Tue, 29 Mar 2016 17:34:08 -0700 [thread overview]
Message-ID: <CAB=NE6XEMdwpafGt5csNGeDe3Y9T8Sw0w27+ryptrUHWYs-t2w@mail.gmail.com> (raw)
In-Reply-To: <1459300060.6393.757.camel@hpe.com>
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
next prev parent reply other threads:[~2016-03-30 0:34 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-11 4:45 [PATCH 0/2] Refactor MTRR and PAT initializations Toshi Kani
2016-03-11 4:45 ` [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table Toshi Kani
2016-03-11 9:12 ` Borislav Petkov
2016-03-11 16:27 ` Toshi Kani
2016-03-11 15:54 ` Borislav Petkov
2016-03-11 19:28 ` Toshi Kani
2016-03-12 11:55 ` Borislav Petkov
2016-03-14 21:37 ` Toshi Kani
2016-03-15 11:00 ` Borislav Petkov
2016-03-15 22:02 ` Toshi Kani
2016-03-15 0:29 ` Luis R. Rodriguez
2016-03-15 3:11 ` Toshi Kani
2016-03-15 3:11 ` Toshi Kani
2016-03-15 11:01 ` Borislav Petkov
2016-03-15 15:43 ` Toshi Kani
2016-03-15 15:43 ` Toshi Kani
2016-03-15 15:47 ` Borislav Petkov
2016-03-15 15:47 ` Borislav Petkov
2016-03-15 17:11 ` Toshi Kani
2016-03-15 16:33 ` Borislav Petkov
2016-03-15 16:33 ` Borislav Petkov
2016-03-15 17:11 ` Toshi Kani
2016-03-15 11:01 ` Borislav Petkov
2016-03-15 21:31 ` Luis R. Rodriguez
2016-03-15 21:31 ` Luis R. Rodriguez
2016-03-15 0:29 ` Luis R. Rodriguez
2016-03-11 4:45 ` [PATCH 2/2] x86/mtrr: Refactor PAT initialization code Toshi Kani
2016-03-11 9:01 ` Ingo Molnar
2016-03-11 9:13 ` Ingo Molnar
2016-03-11 18:34 ` Toshi Kani
2016-03-12 16:18 ` Ingo Molnar
2016-03-14 19:47 ` Toshi Kani
2016-03-14 22:50 ` Luis R. Rodriguez
2016-03-15 0:37 ` Toshi Kani
2016-03-15 15:56 ` Borislav Petkov
2016-03-16 15:44 ` Joe Lawrence
2016-03-11 9:24 ` Borislav Petkov
2016-03-11 18:57 ` Toshi Kani
2016-03-11 22:17 ` Luis R. Rodriguez
2016-03-11 23:56 ` Toshi Kani
2016-03-11 23:34 ` Luis R. Rodriguez
2016-03-12 1:16 ` Toshi Kani
2016-03-15 0:15 ` Luis R. Rodriguez
2016-03-15 23:48 ` Toshi Kani
2016-03-15 23:29 ` Luis R. Rodriguez
2016-03-17 21:56 ` Toshi Kani
2016-03-18 0:06 ` Luis R. Rodriguez
2016-03-18 21:35 ` Toshi Kani
2016-03-29 17:14 ` Luis R. Rodriguez
2016-03-29 21:46 ` Toshi Kani
2016-03-29 22:12 ` Luis R. Rodriguez
2016-03-30 0:16 ` Toshi Kani
2016-03-29 23:43 ` Luis R. Rodriguez
2016-03-30 1:07 ` Toshi Kani
2016-03-30 0:34 ` Luis R. Rodriguez [this message]
2016-04-09 2:04 ` Luis R. Rodriguez
2016-04-11 14:30 ` Toshi Kani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAB=NE6XEMdwpafGt5csNGeDe3Y9T8Sw0w27+ryptrUHWYs-t2w@mail.gmail.com' \
--to=mcgrof@kernel.org \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=olof@lixom.net \
--cc=paul.gortmaker@windriver.com \
--cc=prarit@redhat.com \
--cc=pstew@chromium.org \
--cc=stuart.w.hayes@gmail.com \
--cc=tglx@linutronix.de \
--cc=toshi.kani@hpe.com \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.