Re: [PATCH 11/27] Documentation: x86: convert pat.txt to reST
From: Changbin Du
Date: Thu May 02 2019 - 01:25:42 EST
On Sat, Apr 27, 2019 at 02:51:09PM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 26 Apr 2019 23:31:34 +0800
> Changbin Du <changbin.du@xxxxxxxxx> escreveu:
>
> > This converts the plain text documentation to reStructuredText format and
> > add it to Sphinx TOC tree. No essential content change.
> >
> > Signed-off-by: Changbin Du <changbin.du@xxxxxxxxx>
> > ---
> > Documentation/x86/index.rst | 1 +
> > Documentation/x86/pat.rst | 235 ++++++++++++++++++++++++++++++++++++
> > Documentation/x86/pat.txt | 230 -----------------------------------
> > 3 files changed, 236 insertions(+), 230 deletions(-)
> > create mode 100644 Documentation/x86/pat.rst
> > delete mode 100644 Documentation/x86/pat.txt
> >
> > diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
> > index d805962a7238..e06b5c0ea883 100644
> > --- a/Documentation/x86/index.rst
> > +++ b/Documentation/x86/index.rst
> > @@ -17,3 +17,4 @@ Linux x86 Support
> > zero-page
> > tlb
> > mtrr
> > + pat
> > diff --git a/Documentation/x86/pat.rst b/Documentation/x86/pat.rst
> > new file mode 100644
> > index 000000000000..bf09cab2e0bf
> > --- /dev/null
> > +++ b/Documentation/x86/pat.rst
> > @@ -0,0 +1,235 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +==========================
> > +PAT (Page Attribute Table)
> > +==========================
> > +
> > +x86 Page Attribute Table (PAT) allows for setting the memory attribute at the
> > +page level granularity. PAT is complementary to the MTRR settings which allows
> > +for setting of memory types over physical address ranges. However, PAT is
> > +more flexible than MTRR due to its capability to set attributes at page level
> > +and also due to the fact that there are no hardware limitations on number of
> > +such attribute settings allowed. Added flexibility comes with guidelines for
> > +not having memory type aliasing for the same physical memory with multiple
> > +virtual addresses.
> > +
> > +PAT allows for different types of memory attributes. The most commonly used
> > +ones that will be supported at this time are Write-back, Uncached,
> > +Write-combined, Write-through and Uncached Minus.
>
> I would rewrite the above to:
>
> PAT allows for different types of memory attributes. The most commonly used
> ones that will be supported at this time are:
>
> === ==============
> WB Write-back
> UC Uncached
> WC Write-combined
> WT Write-through
> UC- Uncached Minus
> === ==============
>
> As, at the table below, it uses WB, UC, WC, ... instead the full name. By
> doing this, it makes easier for readers when looking at the next table.
>
Thank you. Looks much better!
> > +
> > +
> > +PAT APIs
> > +========
> > +
> > +There are many different APIs in the kernel that allows setting of memory
> > +attributes at the page level. In order to avoid aliasing, these interfaces
> > +should be used thoughtfully. Below is a table of interfaces available,
> > +their intended usage and their memory attribute relationships. Internally,
> > +these APIs use a reserve_memtype()/free_memtype() interface on the physical
> > +address range to avoid any aliasing.
> > +::
> > +
> > + -------------------------------------------------------------------
> > + API | RAM | ACPI,... | Reserved/Holes |
> > + -----------------------|----------|------------|------------------|
> > + | | | |
> > + ioremap | -- | UC- | UC- |
> > + | | | |
> > + ioremap_cache | -- | WB | WB |
> > + | | | |
> > + ioremap_uc | -- | UC | UC |
> > + | | | |
> > + ioremap_nocache | -- | UC- | UC- |
> > + | | | |
> > + ioremap_wc | -- | -- | WC |
> > + | | | |
> > + ioremap_wt | -- | -- | WT |
> > + | | | |
> > + set_memory_uc | UC- | -- | -- |
> > + set_memory_wb | | | |
> > + | | | |
> > + set_memory_wc | WC | -- | -- |
> > + set_memory_wb | | | |
> > + | | | |
> > + set_memory_wt | WT | -- | -- |
> > + set_memory_wb | | | |
> > + | | | |
> > + pci sysfs resource | -- | -- | UC- |
> > + | | | |
> > + pci sysfs resource_wc | -- | -- | WC |
> > + is IORESOURCE_PREFETCH | | | |
> > + | | | |
> > + pci proc | -- | -- | UC- |
> > + !PCIIOC_WRITE_COMBINE | | | |
> > + | | | |
> > + pci proc | -- | -- | WC |
> > + PCIIOC_WRITE_COMBINE | | | |
> > + | | | |
> > + /dev/mem | -- | WB/WC/UC- | WB/WC/UC- |
> > + read-write | | | |
> > + | | | |
> > + /dev/mem | -- | UC- | UC- |
> > + mmap SYNC flag | | | |
> > + | | | |
> > + /dev/mem | -- | WB/WC/UC- | WB/WC/UC- |
> > + mmap !SYNC flag | |(from exist-| (from exist- |
> > + and | | ing alias)| ing alias) |
> > + any alias to this area | | | |
> > + | | | |
> > + /dev/mem | -- | WB | WB |
> > + mmap !SYNC flag | | | |
> > + no alias to this area | | | |
> > + and | | | |
> > + MTRR says WB | | | |
> > + | | | |
> > + /dev/mem | -- | -- | UC- |
> > + mmap !SYNC flag | | | |
> > + no alias to this area | | | |
> > + and | | | |
> > + MTRR says !WB | | | |
> > + | | | |
> > + -------------------------------------------------------------------
>
> This is already a table. I would keep it like that, just replacing it to
> the proper ReST markups, e. g.:
>
> +------------------------+----------+--------------+------------------+
> | API | RAM | ACPI,... | Reserved/Holes |
> +------------------------+----------+--------------+------------------+
> | ioremap | -- | UC- | UC- |
> +------------------------+----------+--------------+------------------+
> | ioremap_cache | -- | WB | WB |
> +------------------------+----------+--------------+------------------+
> | ioremap_uc | -- | UC | UC |
> +------------------------+----------+--------------+------------------+
> | ioremap_nocache | -- | UC- | UC- |
> +------------------------+----------+--------------+------------------+
> | ioremap_wc | -- | -- | WC |
> +------------------------+----------+--------------+------------------+
> | ioremap_wt | -- | -- | WT |
> +------------------------+----------+--------------+------------------+
> | set_memory_uc, | UC- | -- | -- |
> | set_memory_wb | | | |
> +------------------------+----------+--------------+------------------+
> | set_memory_wc, | WC | -- | -- |
> | set_memory_wb | | | |
> +------------------------+----------+--------------+------------------+
> | set_memory_wt, | WT | -- | -- |
> | set_memory_wb | | | |
> +------------------------+----------+--------------+------------------+
> | pci sysfs resource | -- | -- | UC- |
> +------------------------+----------+--------------+------------------+
> | pci sysfs resource_wc | -- | -- | WC |
> | is IORESOURCE_PREFETCH | | | |
> +------------------------+----------+--------------+------------------+
> | pci proc | -- | -- | UC- |
> | !PCIIOC_WRITE_COMBINE | | | |
> +------------------------+----------+--------------+------------------+
> | pci proc | -- | -- | WC |
> | PCIIOC_WRITE_COMBINE | | | |
> +------------------------+----------+--------------+------------------+
> | /dev/mem | -- | WB/WC/UC- | WB/WC/UC- |
> | read-write | | | |
> +------------------------+----------+--------------+------------------+
> | /dev/mem | -- | UC- | UC- |
> | mmap SYNC flag | | | |
> +------------------------+----------+--------------+------------------+
> | /dev/mem | -- | WB/WC/UC- | WB/WC/UC- |
> | mmap !SYNC flag | | | |
> | and | |(from existing| (from existing |
> | any alias to this area | |alias) | alias) |
> +------------------------+----------+--------------+------------------+
> | /dev/mem | -- | WB | WB |
> | mmap !SYNC flag | | | |
> | no alias to this area | | | |
> | and | | | |
> | MTRR says WB | | | |
> +------------------------+----------+--------------+------------------+
> | /dev/mem | -- | -- | UC- |
> | mmap !SYNC flag | | | |
> | no alias to this area | | | |
> | and | | | |
> | MTRR says !WB | | | |
> +------------------------+----------+--------------+------------------+
>
Copied your content. Thank you~
>
> > +
> > +Advanced APIs for drivers
> > +=========================
> > +
> > +A. Exporting pages to users with remap_pfn_range, io_remap_pfn_range,
> > +vmf_insert_pfn.
> > +
> > +Drivers wanting to export some pages to userspace do it by using mmap
> > +interface and a combination of:
> > +
> > + 1) pgprot_noncached()
> > + 2) io_remap_pfn_range() or remap_pfn_range() or vmf_insert_pfn()
> > +
> > +With PAT support, a new API pgprot_writecombine is being added. So, drivers can
> > +continue to use the above sequence, with either pgprot_noncached() or
> > +pgprot_writecombine() in step 1, followed by step 2.
> > +
> > +In addition, step 2 internally tracks the region as UC or WC in memtype
> > +list in order to ensure no conflicting mapping.
> > +
> > +Note that this set of APIs only works with IO (non RAM) regions. If driver
> > +wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
> > +as step 0 above and also track the usage of those pages and use set_memory_wb()
> > +before the page is freed to free pool.
> > +
> > +MTRR effects on PAT / non-PAT systems
> > +=====================================
> > +
> > +The following table provides the effects of using write-combining MTRRs when
> > +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> > +mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
> > +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> > +is made, should already have been ioremapped with WC attributes or PAT entries,
> > +this can be done by using ioremap_wc() / set_memory_wc(). Devices which
> > +combine areas of IO memory desired to remain uncacheable with areas where
> > +write-combining is desirable should consider use of ioremap_uc() followed by
> > +set_memory_wc() to white-list effective write-combined areas. Such use is
> > +nevertheless discouraged as the effective memory type is considered
> > +implementation defined, yet this strategy can be used as last resort on devices
> > +with size-constrained regions where otherwise MTRR write-combining would
> > +otherwise not be effective.
> > +::
> > +
> > + ----------------------------------------------------------------------
> > + MTRR Non-PAT PAT Linux ioremap value Effective memory type
> > + ----------------------------------------------------------------------
> > + Non-PAT | PAT
> > + PAT
> > + |PCD
> > + ||PWT
> > + |||
> > + WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> > + WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> > + WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC
> > + WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> > + ----------------------------------------------------------------------
> > +
> > +(*) denotes implementation defined and is discouraged
>
> The (*) here is part of the artwork. So, it should be indented, in order to
> make easier for someone reading this on html mode.
>
> As you know, before noticing your conversion, I made my own changes to
> x86. There, for this particular artwork, I did some cosmetic changes,
> to make it look more similar to other tables, as, IMHO, having a similar
> visual makes easier for one reading this in text format:
>
> ==== ======= === ========================= =====================
> MTRR Non-PAT PAT Linux ioremap value Effective memory type
> ==== ======= === ========================= =====================
> PAT Non-PAT | PAT
> |PCD |
> ||PWT |
> ||| |
> WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC
> WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> ==== ======= === ========================= =====================
>
> (*) denotes implementation defined and is discouraged
>
> (unfortunately, even looking like a table, Sphinx won't parse it fine,
> so, even if you opt to use the above, we still need to mark it as
> a literal block)
>
Ditto. Thanks.
> It is up to you (and x86 maintainers) to choose between the
> versions. Of course, I prefer the one I did, as it is visually
> closer to what we're doing on most tables, so my brain can parse
> it faster.
>
> > +
> > +.. note:: -- in the above table mean "Not suggested usage for the API". Some
> > + of the --'s are strictly enforced by the kernel. Some others are not really
> > + enforced today, but may be enforced in future.
> > +
> > +For ioremap and pci access through /sys or /proc - The actual type returned
> > +can be more restrictive, in case of any existing aliasing for that address.
> > +For example: If there is an existing uncached mapping, a new ioremap_wc can
> > +return uncached mapping in place of write-combine requested.
> > +
> > +set_memory_[uc|wc|wt] and set_memory_wb should be used in pairs, where driver
> > +will first make a region uc, wc or wt and switch it back to wb after use.
> > +
> > +Over time writes to /proc/mtrr will be deprecated in favor of using PAT based
> > +interfaces. Users writing to /proc/mtrr are suggested to use above interfaces.
> > +
> > +Drivers should use ioremap_[uc|wc] to access PCI BARs with [uc|wc] access
> > +types.
> > +
> > +Drivers should use set_memory_[uc|wc|wt] to set access type for RAM ranges.
> > +
> > +
> > +PAT debugging
> > +=============
> > +
> > +With CONFIG_DEBUG_FS enabled, PAT memtype list can be examined by::
> > +
> > + # mount -t debugfs debugfs /sys/kernel/debug
> > + # cat /sys/kernel/debug/x86/pat_memtype_list
> > + PAT memtype list:
> > + uncached-minus @ 0x7fadf000-0x7fae0000
> > + uncached-minus @ 0x7fb19000-0x7fb1a000
> > + uncached-minus @ 0x7fb1a000-0x7fb1b000
> > + uncached-minus @ 0x7fb1b000-0x7fb1c000
> > + uncached-minus @ 0x7fb1c000-0x7fb1d000
> > + uncached-minus @ 0x7fb1d000-0x7fb1e000
> > + uncached-minus @ 0x7fb1e000-0x7fb25000
> > + uncached-minus @ 0x7fb25000-0x7fb26000
> > + uncached-minus @ 0x7fb26000-0x7fb27000
> > + uncached-minus @ 0x7fb27000-0x7fb28000
> > + uncached-minus @ 0x7fb28000-0x7fb2e000
> > + uncached-minus @ 0x7fb2e000-0x7fb2f000
> > + uncached-minus @ 0x7fb2f000-0x7fb30000
> > + uncached-minus @ 0x7fb31000-0x7fb32000
> > + uncached-minus @ 0x80000000-0x90000000
> > +
> > +This list shows physical address ranges and various PAT settings used to
> > +access those physical address ranges.
> > +
> > +Another, more verbose way of getting PAT related debug messages is with
> > +"debugpat" boot parameter. With this parameter, various debug messages are
> > +printed to dmesg log.
> > +
> > +PAT Initialization
> > +==================
> > +
> > +The following table describes how PAT is initialized under various
> > +configurations. The PAT MSR must be updated by Linux in order to support WC
> > +and WT attributes. Otherwise, the PAT MSR has the value programmed in it
> > +by the firmware. Note, Xen enables WC attribute in the PAT MSR for guests.
> > +::
> > +
> > + MTRR PAT Call Sequence PAT State PAT MSR
> > + =========================================================
> > + E E MTRR -> PAT init Enabled OS
> > + E D MTRR -> PAT init Disabled -
> > + D E MTRR -> PAT disable Disabled BIOS
> > + D D MTRR -> PAT disable Disabled -
> > + - np/E PAT -> PAT disable Disabled BIOS
> > + - np/D PAT -> PAT disable Disabled -
> > + E !P/E MTRR -> PAT init Disabled BIOS
> > + D !P/E MTRR -> PAT disable Disabled BIOS
> > + !M !P/E MTRR stub -> PAT disable Disabled BIOS
> > +
> > + Legend
> > + ------------------------------------------------
> > + E Feature enabled in CPU
> > + D Feature disabled/unsupported in CPU
> > + np "nopat" boot option specified
> > + !P CONFIG_X86_PAT option unset
> > + !M CONFIG_MTRR option unset
> > + Enabled PAT state set to enabled
> > + Disabled PAT state set to disabled
> > + OS PAT initializes PAT MSR with OS setting
> > + BIOS PAT keeps PAT MSR with BIOS setting
> > +
>
> Those are actually two tables. Please mark them as such, e. g.:
>
> ==== ===== ========================== ========= =======
> MTRR PAT Call Sequence PAT State PAT MSR
> ==== ===== ========================== ========= =======
> E E MTRR -> PAT init Enabled OS
> E D MTRR -> PAT init Disabled -
> D E MTRR -> PAT disable Disabled BIOS
> D D MTRR -> PAT disable Disabled -
> - np/E PAT -> PAT disable Disabled BIOS
> - np/D PAT -> PAT disable Disabled -
> E !P/E MTRR -> PAT init Disabled BIOS
> D !P/E MTRR -> PAT disable Disabled BIOS
> !M !P/E MTRR stub -> PAT disable Disabled BIOS
> ==== ===== ========================== ========= =======
>
> Legend
>
> ========= =======================================
> E Feature enabled in CPU
> D Feature disabled/unsupported in CPU
> np "nopat" boot option specified
> !P CONFIG_X86_PAT option unset
> !M CONFIG_MTRR option unset
> Enabled PAT state set to enabled
> Disabled PAT state set to disabled
> OS PAT initializes PAT MSR with OS setting
> BIOS PAT keeps PAT MSR with BIOS setting
> ========= =======================================
>
All are table now.
>
>
>
> > diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> > deleted file mode 100644
> > index 481d8d8536ac..000000000000
> > --- a/Documentation/x86/pat.txt
> > +++ /dev/null
> > @@ -1,230 +0,0 @@
> > -
> > -PAT (Page Attribute Table)
> > -
> > -x86 Page Attribute Table (PAT) allows for setting the memory attribute at the
> > -page level granularity. PAT is complementary to the MTRR settings which allows
> > -for setting of memory types over physical address ranges. However, PAT is
> > -more flexible than MTRR due to its capability to set attributes at page level
> > -and also due to the fact that there are no hardware limitations on number of
> > -such attribute settings allowed. Added flexibility comes with guidelines for
> > -not having memory type aliasing for the same physical memory with multiple
> > -virtual addresses.
> > -
> > -PAT allows for different types of memory attributes. The most commonly used
> > -ones that will be supported at this time are Write-back, Uncached,
> > -Write-combined, Write-through and Uncached Minus.
> > -
> > -
> > -PAT APIs
> > ---------
> > -
> > -There are many different APIs in the kernel that allows setting of memory
> > -attributes at the page level. In order to avoid aliasing, these interfaces
> > -should be used thoughtfully. Below is a table of interfaces available,
> > -their intended usage and their memory attribute relationships. Internally,
> > -these APIs use a reserve_memtype()/free_memtype() interface on the physical
> > -address range to avoid any aliasing.
> > -
> > -
> > --------------------------------------------------------------------
> > -API | RAM | ACPI,... | Reserved/Holes |
> > ------------------------|----------|------------|------------------|
> > - | | | |
> > -ioremap | -- | UC- | UC- |
> > - | | | |
> > -ioremap_cache | -- | WB | WB |
> > - | | | |
> > -ioremap_uc | -- | UC | UC |
> > - | | | |
> > -ioremap_nocache | -- | UC- | UC- |
> > - | | | |
> > -ioremap_wc | -- | -- | WC |
> > - | | | |
> > -ioremap_wt | -- | -- | WT |
> > - | | | |
> > -set_memory_uc | UC- | -- | -- |
> > - set_memory_wb | | | |
> > - | | | |
> > -set_memory_wc | WC | -- | -- |
> > - set_memory_wb | | | |
> > - | | | |
> > -set_memory_wt | WT | -- | -- |
> > - set_memory_wb | | | |
> > - | | | |
> > -pci sysfs resource | -- | -- | UC- |
> > - | | | |
> > -pci sysfs resource_wc | -- | -- | WC |
> > - is IORESOURCE_PREFETCH| | | |
> > - | | | |
> > -pci proc | -- | -- | UC- |
> > - !PCIIOC_WRITE_COMBINE | | | |
> > - | | | |
> > -pci proc | -- | -- | WC |
> > - PCIIOC_WRITE_COMBINE | | | |
> > - | | | |
> > -/dev/mem | -- | WB/WC/UC- | WB/WC/UC- |
> > - read-write | | | |
> > - | | | |
> > -/dev/mem | -- | UC- | UC- |
> > - mmap SYNC flag | | | |
> > - | | | |
> > -/dev/mem | -- | WB/WC/UC- | WB/WC/UC- |
> > - mmap !SYNC flag | |(from exist-| (from exist- |
> > - and | | ing alias)| ing alias) |
> > - any alias to this area| | | |
> > - | | | |
> > -/dev/mem | -- | WB | WB |
> > - mmap !SYNC flag | | | |
> > - no alias to this area | | | |
> > - and | | | |
> > - MTRR says WB | | | |
> > - | | | |
> > -/dev/mem | -- | -- | UC- |
> > - mmap !SYNC flag | | | |
> > - no alias to this area | | | |
> > - and | | | |
> > - MTRR says !WB | | | |
> > - | | | |
> > --------------------------------------------------------------------
> > -
> > -Advanced APIs for drivers
> > --------------------------
> > -A. Exporting pages to users with remap_pfn_range, io_remap_pfn_range,
> > -vmf_insert_pfn
> > -
> > -Drivers wanting to export some pages to userspace do it by using mmap
> > -interface and a combination of
> > -1) pgprot_noncached()
> > -2) io_remap_pfn_range() or remap_pfn_range() or vmf_insert_pfn()
> > -
> > -With PAT support, a new API pgprot_writecombine is being added. So, drivers can
> > -continue to use the above sequence, with either pgprot_noncached() or
> > -pgprot_writecombine() in step 1, followed by step 2.
> > -
> > -In addition, step 2 internally tracks the region as UC or WC in memtype
> > -list in order to ensure no conflicting mapping.
> > -
> > -Note that this set of APIs only works with IO (non RAM) regions. If driver
> > -wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
> > -as step 0 above and also track the usage of those pages and use set_memory_wb()
> > -before the page is freed to free pool.
> > -
> > -MTRR effects on PAT / non-PAT systems
> > --------------------------------------
> > -
> > -The following table provides the effects of using write-combining MTRRs when
> > -using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> > -mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
> > -be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> > -is made, should already have been ioremapped with WC attributes or PAT entries,
> > -this can be done by using ioremap_wc() / set_memory_wc(). Devices which
> > -combine areas of IO memory desired to remain uncacheable with areas where
> > -write-combining is desirable should consider use of ioremap_uc() followed by
> > -set_memory_wc() to white-list effective write-combined areas. Such use is
> > -nevertheless discouraged as the effective memory type is considered
> > -implementation defined, yet this strategy can be used as last resort on devices
> > -with size-constrained regions where otherwise MTRR write-combining would
> > -otherwise not be effective.
> > -
> > -----------------------------------------------------------------------
> > -MTRR Non-PAT PAT Linux ioremap value Effective memory type
> > -----------------------------------------------------------------------
> > - Non-PAT | PAT
> > - PAT
> > - |PCD
> > - ||PWT
> > - |||
> > -WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> > -WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> > -WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC
> > -WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> > -----------------------------------------------------------------------
> > -
> > -(*) denotes implementation defined and is discouraged
> > -
> > -Notes:
> > -
> > --- in the above table mean "Not suggested usage for the API". Some of the --'s
> > -are strictly enforced by the kernel. Some others are not really enforced
> > -today, but may be enforced in future.
> > -
> > -For ioremap and pci access through /sys or /proc - The actual type returned
> > -can be more restrictive, in case of any existing aliasing for that address.
> > -For example: If there is an existing uncached mapping, a new ioremap_wc can
> > -return uncached mapping in place of write-combine requested.
> > -
> > -set_memory_[uc|wc|wt] and set_memory_wb should be used in pairs, where driver
> > -will first make a region uc, wc or wt and switch it back to wb after use.
> > -
> > -Over time writes to /proc/mtrr will be deprecated in favor of using PAT based
> > -interfaces. Users writing to /proc/mtrr are suggested to use above interfaces.
> > -
> > -Drivers should use ioremap_[uc|wc] to access PCI BARs with [uc|wc] access
> > -types.
> > -
> > -Drivers should use set_memory_[uc|wc|wt] to set access type for RAM ranges.
> > -
> > -
> > -PAT debugging
> > --------------
> > -
> > -With CONFIG_DEBUG_FS enabled, PAT memtype list can be examined by
> > -
> > -# mount -t debugfs debugfs /sys/kernel/debug
> > -# cat /sys/kernel/debug/x86/pat_memtype_list
> > -PAT memtype list:
> > -uncached-minus @ 0x7fadf000-0x7fae0000
> > -uncached-minus @ 0x7fb19000-0x7fb1a000
> > -uncached-minus @ 0x7fb1a000-0x7fb1b000
> > -uncached-minus @ 0x7fb1b000-0x7fb1c000
> > -uncached-minus @ 0x7fb1c000-0x7fb1d000
> > -uncached-minus @ 0x7fb1d000-0x7fb1e000
> > -uncached-minus @ 0x7fb1e000-0x7fb25000
> > -uncached-minus @ 0x7fb25000-0x7fb26000
> > -uncached-minus @ 0x7fb26000-0x7fb27000
> > -uncached-minus @ 0x7fb27000-0x7fb28000
> > -uncached-minus @ 0x7fb28000-0x7fb2e000
> > -uncached-minus @ 0x7fb2e000-0x7fb2f000
> > -uncached-minus @ 0x7fb2f000-0x7fb30000
> > -uncached-minus @ 0x7fb31000-0x7fb32000
> > -uncached-minus @ 0x80000000-0x90000000
> > -
> > -This list shows physical address ranges and various PAT settings used to
> > -access those physical address ranges.
> > -
> > -Another, more verbose way of getting PAT related debug messages is with
> > -"debugpat" boot parameter. With this parameter, various debug messages are
> > -printed to dmesg log.
> > -
> > -PAT Initialization
> > -------------------
> > -
> > -The following table describes how PAT is initialized under various
> > -configurations. The PAT MSR must be updated by Linux in order to support WC
> > -and WT attributes. Otherwise, the PAT MSR has the value programmed in it
> > -by the firmware. Note, Xen enables WC attribute in the PAT MSR for guests.
> > -
> > - MTRR PAT Call Sequence PAT State PAT MSR
> > - =========================================================
> > - E E MTRR -> PAT init Enabled OS
> > - E D MTRR -> PAT init Disabled -
> > - D E MTRR -> PAT disable Disabled BIOS
> > - D D MTRR -> PAT disable Disabled -
> > - - np/E PAT -> PAT disable Disabled BIOS
> > - - np/D PAT -> PAT disable Disabled -
> > - E !P/E MTRR -> PAT init Disabled BIOS
> > - D !P/E MTRR -> PAT disable Disabled BIOS
> > - !M !P/E MTRR stub -> PAT disable Disabled BIOS
> > -
> > - Legend
> > - ------------------------------------------------
> > - E Feature enabled in CPU
> > - D Feature disabled/unsupported in CPU
> > - np "nopat" boot option specified
> > - !P CONFIG_X86_PAT option unset
> > - !M CONFIG_MTRR option unset
> > - Enabled PAT state set to enabled
> > - Disabled PAT state set to disabled
> > - OS PAT initializes PAT MSR with OS setting
> > - BIOS PAT keeps PAT MSR with BIOS setting
> > -
>
>
>
> Thanks,
> Mauro
--
Cheers,
Changbin Du