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: > > On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani <toshi.kani@xxxxxx> wrote: > > > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote: > > > > On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani <toshi.kani@xxxxxx> > > > > wrote: > > > > > On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote: > > > > > > On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani <toshi.kani@xxxxxx> > > > > > > wrote: > : > > > > > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
