On Fri, 2015-08-07 at 17:08 -0600, Toshi Kani wrote:

On Fri, 2015-08-07 at 15:23 -0700, Luis R. Rodriguez wrote:

quoted

On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani [off-list ref] wrote:

quoted

On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote:

quoted

On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani [off-list ref] 
wrote:

quoted

On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote:

quoted

On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani [off-list ref] 
wrote:

 :

quoted

quoted

quoted

quoted

No, there is no OS support necessary to use MTRR.  After firmware 
sets it up, CPUs continue to use it without any OS support.  I 
think the Linux change you are referring is to obsolete legacy
interfaces that modify the MTRR setup.  I agree that Linux should 
not modify MTRR.

Its a bit more than that though. Since you agree that the OS can 
live without MTRR code I was hoping to then see if we can fold out 
PAT Linux code from under the MTRR dependency on Linux and make PAT 
a first class citizen, maybe at least for x86-64. Right now you can
only get PAT support on Linux if you have MTRR code, but I'd like to 
see if instead we can rip MTRR code out completely under its own 
Kconfig and let it start rotting away.

Code-wise the only issue I saw was that PAT code also relies on
mtrr_type_lookup(), see pat_x_mtrr_type(), but other than this I 
found no other obvious issues.

We can rip of the MTTR code that modifies the MTRR setup, but not
mtrr_type_lookup().  This function provides necessary checks per 
documented in commit 7f0431e3dc89 as follows.

    1) reserve_memtype() tracks an effective memory type in case
       a request type is WB (ex. /dev/mem blindly uses WB). Missing
       to track with its effective type causes a subsequent request
       to map the same range with the effective type to fail.

    2) pud_set_huge() and pmd_set_huge() check if a requested range
       has any overlap with MTRRs. Missing to detect an overlap may
       cause a performance penalty or undefined behavior.

mtrr_type_lookup() is still admittedly awkward, but I do not think we 
have an immediate issue in PAT code calling it.  I do not think it 
makes 
PAT code a second class citizen.

OK since we know that if MTRR set up code ends up disabled and would
return MTRR_TYPE_INVALID what if we just static inline this for the
no-MTRR Kconfig build option immediately, and only then have the full
blown implementation for the case where MTRR Kconfig option is
enabled?

Yes, the MTRR code could be disabled by Kconfig with such inline stubs as
long as the kernel is built specifically for a particular platform with 
MTRR disabled, such as Xen guest kernel.

Noticed that we do have CONFIG_MTRR and mtrr_type_lookup() inline stub
returns MTRR_INVALID.

-Toshi