All of lore.kernel.org
 help / color / mirror / Atom feed
From: Toshi Kani <toshi.kani@hpe.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: Prarit Bhargava <prarit@redhat.com>,
	Stuart Hayes <stuart.w.hayes@gmail.com>,
	tglx@linutronix.de, mingo@redhat.com,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	mcgrof@do-not-panic.com, Toshi Kani <toshi.kani@hp.com>
Subject: Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup
Date: Thu, 03 Sep 2015 16:25:31 -0600	[thread overview]
Message-ID: <1441319131.3277.54.camel@hpe.com> (raw)
In-Reply-To: <20150903220711.GX8051@wotan.suse.de>

On Fri, 2015-09-04 at 00:07 +0200, Luis R. Rodriguez wrote:
 :
> These are still at odds, for instance, I was under the impression we can
> just have the OS return MTRR_TYPE_INVALID if the OS / drivers never used
> or set up MTRR, but the platform did, above (not the patch) you seem to be
> saying that even if the OS didn't modify MTRRs the OS still needs to return
> the appropriately set up MTRR type by firmware. This is different. Can you
> clarify?

mtrr_type_lookup() returns valid MTRR cache type for a given address range
when MTRRs are enabled.  It does not matter if MTRRs are set by the firmware
or the OS.  When MTRRs are enabled, the kernel needs to check through
mtrr_type_lookup() that large page mapping requests are aligned with MTRRs.

On Xen, or on a platform with firmware that does not enable MTRRs,
mtrr_type_lookup() returns MTRR_TYPE_INVALID (as long as the kernel does not
enable them).

Thanks,
-Toshi

  reply	other threads:[~2015-09-03 22:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <55E477DE.2060106@gmail.com>
2015-08-31 16:05 ` Stuart Hayes
2015-09-03  2:45   ` Luis R. Rodriguez
2015-09-03 12:17     ` Prarit Bhargava
2015-09-03 17:59       ` Luis R. Rodriguez
2015-09-03 18:10         ` Prarit Bhargava
2015-09-03 18:40           ` Luis R. Rodriguez
2015-09-03 19:22             ` Toshi Kani
2015-09-03 19:51               ` Luis R. Rodriguez
2015-09-03 21:31                 ` Toshi Kani
2015-09-03 22:07                   ` Luis R. Rodriguez
2015-09-03 22:25                     ` Toshi Kani [this message]
2015-09-03 22:45                       ` Luis R. Rodriguez
2015-09-03 23:21                         ` Toshi Kani
2015-09-03 23:54                           ` Luis R. Rodriguez
2015-09-04  0:48                             ` Toshi Kani
2015-09-04  1:40                               ` Luis R. Rodriguez
2015-09-04 14:56                                 ` Toshi Kani
2015-09-04  6:51                             ` Jan Beulich
2015-09-14 14:46       ` Stuart Hayes
2015-11-05 19:14         ` Yinghai Lu
2015-11-05 19:43           ` Luis R. Rodriguez
2016-03-16 20:20             ` Luis R. Rodriguez
2016-03-29 17:07               ` Luis R. Rodriguez

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=1441319131.3277.54.camel@hpe.com \
    --to=toshi.kani@hpe.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    --cc=mcgrof@suse.com \
    --cc=mingo@redhat.com \
    --cc=prarit@redhat.com \
    --cc=stuart.w.hayes@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=toshi.kani@hp.com \
    --cc=x86@kernel.org \
    --subject='Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup' \
    /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

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.