[PATCH v2 0/6] Support Write-Through mapping on x86

[PATCH v2 0/6] Support Write-Through mapping on x86

[Toshi Kani]

This patchset adds support of Write-Through (WT) mapping on x86.
The study below shows that using WT mapping may be useful for
non-volatile memory.

  http://www.hpl.hp.com/techreports/2012/HPL-2012-236.pdf

This patchset applies on top of the Juergen's patchset below,
which provides the basis of the PAT management.

  https://lkml.org/lkml/2014/9/8/55

All new/modified interfaces have been tested.

v2:
 - Changed WT to use slot 7 of the PAT MSR. (H. Peter Anvin,
   Andy Lutomirski)
 - Changed to have conservative checks to exclude all Pentium 2, 3,
   M, and 4 families. (Ingo Molnar, Henrique de Moraes Holschuh,
   Andy Lutomirski)
 - Updated documentation to cover WT interfaces and usages.
   (Andy Lutomirski, Yigal Korman)

---
Toshi Kani (6):
  1/6 x86, mm, pat: Set WT to PA4 slot of PAT MSR
  2/6 x86, mm, pat: Change reserve_memtype() to handle WT
  3/6 x86, mm, asm-gen: Add ioremap_wt() for WT
  4/6 x86, mm: Add set_memory_wt() for WT
  5/6 x86, mm, pat: Add pgprot_writethrough() for WT
  6/6 x86, pat: Update documentation for WT changes

---
 Documentation/x86/pat.txt            | 14 +++++--
 arch/x86/include/asm/cacheflush.h    | 10 ++++-
 arch/x86/include/asm/io.h            |  2 +
 arch/x86/include/asm/pgtable_types.h |  3 ++
 arch/x86/mm/ioremap.c                | 24 ++++++++++++
 arch/x86/mm/pageattr.c               | 73 +++++++++++++++++++++++++++++++++---
 arch/x86/mm/pat.c                    | 69 +++++++++++++++++++++++++---------
 include/asm-generic/io.h             |  4 ++
 include/asm-generic/iomap.h          |  4 ++
 include/asm-generic/pgtable.h        |  4 ++
 10 files changed, 179 insertions(+), 28 deletions(-)

[PATCH v2 0/6] Support Write-Through mapping on x86

[Toshi Kani]

This patchset adds support of Write-Through (WT) mapping on x86.
The study below shows that using WT mapping may be useful for
non-volatile memory.

  http://www.hpl.hp.com/techreports/2012/HPL-2012-236.pdf

This patchset applies on top of the Juergen's patchset below,
which provides the basis of the PAT management.

  https://lkml.org/lkml/2014/9/8/55

All new/modified interfaces have been tested.

v2:
 - Changed WT to use slot 7 of the PAT MSR. (H. Peter Anvin,
   Andy Lutomirski)
 - Changed to have conservative checks to exclude all Pentium 2, 3,
   M, and 4 families. (Ingo Molnar, Henrique de Moraes Holschuh,
   Andy Lutomirski)
 - Updated documentation to cover WT interfaces and usages.
   (Andy Lutomirski, Yigal Korman)

---
Toshi Kani (6):
  1/6 x86, mm, pat: Set WT to PA4 slot of PAT MSR
  2/6 x86, mm, pat: Change reserve_memtype() to handle WT
  3/6 x86, mm, asm-gen: Add ioremap_wt() for WT
  4/6 x86, mm: Add set_memory_wt() for WT
  5/6 x86, mm, pat: Add pgprot_writethrough() for WT
  6/6 x86, pat: Update documentation for WT changes

---
 Documentation/x86/pat.txt            | 14 +++++--
 arch/x86/include/asm/cacheflush.h    | 10 ++++-
 arch/x86/include/asm/io.h            |  2 +
 arch/x86/include/asm/pgtable_types.h |  3 ++
 arch/x86/mm/ioremap.c                | 24 ++++++++++++
 arch/x86/mm/pageattr.c               | 73 +++++++++++++++++++++++++++++++++---
 arch/x86/mm/pat.c                    | 69 +++++++++++++++++++++++++---------
 include/asm-generic/io.h             |  4 ++
 include/asm-generic/iomap.h          |  4 ++
 include/asm-generic/pgtable.h        |  4 ++
 10 files changed, 179 insertions(+), 28 deletions(-)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH v2 1/6] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

This patch sets WT to the PA7 slot in the PAT MSR when the processor
is not affected by the PAT errata.  The PA7 slot is chosen to further
minimize the risk of using the PAT bit as the PA3 slot is UC and is
not currently used.

The following Intel processors are affected by the PAT errata.

   errata               cpuid
   ----------------------------------------------------
   Pentium 2, A52       family 0x6, model 0x5
   Pentium 3, E27       family 0x6, model 0x7, 0x8
   Pentium 3 Xenon, G26 family 0x6, model 0x7, 0x8, 0xa
   Pentium M, Y26       family 0x6, model 0x9
   Pentium M 90nm, X9   family 0x6, model 0xd
   Pentium 4, N46       family 0xf, model 0x0

Instead of making sharp boundary checks, this patch makes conservative
checks to exclude all Pentium 2, 3, M and 4 family processors.  For
such processors, _PAGE_CACHE_MODE_WT is redirected to UC- per the
default setup in __cachemode2pte_tbl[].

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 arch/x86/mm/pat.c |   43 ++++++++++++++++++++++++++++---------------
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index ff31851..598d7c7 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -133,6 +133,7 @@ void pat_init(void)
 {
 	u64 pat;
 	bool boot_cpu = !boot_pat_state;
+	struct cpuinfo_x86 *c = &boot_cpu_data;
 
 	if (!pat_enabled)
 		return;
@@ -153,21 +154,33 @@ void pat_init(void)
 		}
 	}
 
-	/* Set PWT to Write-Combining. All other bits stay the same */
-	/*
-	 * PTE encoding used in Linux:
-	 *      PAT
-	 *      |PCD
-	 *      ||PWT
-	 *      |||
-	 *      000 WB		_PAGE_CACHE_WB
-	 *      001 WC		_PAGE_CACHE_WC
-	 *      010 UC-		_PAGE_CACHE_UC_MINUS
-	 *      011 UC		_PAGE_CACHE_UC
-	 * PAT bit unused
-	 */
-	pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
-	      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
+	if ((c->x86_vendor == X86_VENDOR_INTEL) &&
+	    (((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
+	     ((c->x86 == 0xf) && (c->x86_model <= 0x6)))) {
+		/*
+		 * Intel Pentium 2, 3, M, and 4 are affected by PAT errata,
+		 * which makes the upper four entries unusable.  We do not
+		 * use the upper four entries for all the affected processor
+		 * families for safe.
+		 *
+		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-7:unusable
+		 *
+		 * NOTE: When WT or WP is used, it is redirected to UC- per
+		 * the default setup in  __cachemode2pte_tbl[].
+		 */
+		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
+		      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
+	} else {
+		/*
+		 * WT is set to slot 7, which minimizes the risk of using
+		 * the PAT bit as slot 3 is UC and is currently unused.
+		 * Slot 4 should remain as reserved.
+		 *
+		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-6:reserved, 7:WT
+		 */
+		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
+		      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, WT);
+	}
 
 	/* Boot CPU check */
 	if (!boot_pat_state)

[PATCH v2 1/6] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

This patch sets WT to the PA7 slot in the PAT MSR when the processor
is not affected by the PAT errata.  The PA7 slot is chosen to further
minimize the risk of using the PAT bit as the PA3 slot is UC and is
not currently used.

The following Intel processors are affected by the PAT errata.

   errata               cpuid
   ----------------------------------------------------
   Pentium 2, A52       family 0x6, model 0x5
   Pentium 3, E27       family 0x6, model 0x7, 0x8
   Pentium 3 Xenon, G26 family 0x6, model 0x7, 0x8, 0xa
   Pentium M, Y26       family 0x6, model 0x9
   Pentium M 90nm, X9   family 0x6, model 0xd
   Pentium 4, N46       family 0xf, model 0x0

Instead of making sharp boundary checks, this patch makes conservative
checks to exclude all Pentium 2, 3, M and 4 family processors.  For
such processors, _PAGE_CACHE_MODE_WT is redirected to UC- per the
default setup in __cachemode2pte_tbl[].

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 arch/x86/mm/pat.c |   43 ++++++++++++++++++++++++++++---------------
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index ff31851..598d7c7 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -133,6 +133,7 @@ void pat_init(void)
 {
 	u64 pat;
 	bool boot_cpu = !boot_pat_state;
+	struct cpuinfo_x86 *c = &boot_cpu_data;
 
 	if (!pat_enabled)
 		return;
@@ -153,21 +154,33 @@ void pat_init(void)
 		}
 	}
 
-	/* Set PWT to Write-Combining. All other bits stay the same */
-	/*
-	 * PTE encoding used in Linux:
-	 *      PAT
-	 *      |PCD
-	 *      ||PWT
-	 *      |||
-	 *      000 WB		_PAGE_CACHE_WB
-	 *      001 WC		_PAGE_CACHE_WC
-	 *      010 UC-		_PAGE_CACHE_UC_MINUS
-	 *      011 UC		_PAGE_CACHE_UC
-	 * PAT bit unused
-	 */
-	pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
-	      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
+	if ((c->x86_vendor == X86_VENDOR_INTEL) &&
+	    (((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
+	     ((c->x86 == 0xf) && (c->x86_model <= 0x6)))) {
+		/*
+		 * Intel Pentium 2, 3, M, and 4 are affected by PAT errata,
+		 * which makes the upper four entries unusable.  We do not
+		 * use the upper four entries for all the affected processor
+		 * families for safe.
+		 *
+		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-7:unusable
+		 *
+		 * NOTE: When WT or WP is used, it is redirected to UC- per
+		 * the default setup in  __cachemode2pte_tbl[].
+		 */
+		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
+		      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
+	} else {
+		/*
+		 * WT is set to slot 7, which minimizes the risk of using
+		 * the PAT bit as slot 3 is UC and is currently unused.
+		 * Slot 4 should remain as reserved.
+		 *
+		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-6:reserved, 7:WT
+		 */
+		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
+		      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, WT);
+	}
 
 	/* Boot CPU check */
 	if (!boot_pat_state)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/6] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Konrad Rzeszutek Wilk]

> -	/* Set PWT to Write-Combining. All other bits stay the same */
> -	/*
> -	 * PTE encoding used in Linux:
> -	 *      PAT
> -	 *      |PCD
> -	 *      ||PWT
> -	 *      |||
> -	 *      000 WB		_PAGE_CACHE_WB
> -	 *      001 WC		_PAGE_CACHE_WC
> -	 *      010 UC-		_PAGE_CACHE_UC_MINUS
> -	 *      011 UC		_PAGE_CACHE_UC


I think having this nice picture would be beneficial to folks
who want to understand it. And now you can of course expand it with
the slot 7 usage.

> -	 * PAT bit unused
> -	 */
> -	pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> -	      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
> +	if ((c->x86_vendor == X86_VENDOR_INTEL) &&
> +	    (((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
> +	     ((c->x86 == 0xf) && (c->x86_model <= 0x6)))) {
> +		/*
> +		 * Intel Pentium 2, 3, M, and 4 are affected by PAT errata,
> +		 * which makes the upper four entries unusable.  We do not
> +		 * use the upper four entries for all the affected processor
> +		 * families for safe.
> +		 *
> +		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-7:unusable
> +		 *
> +		 * NOTE: When WT or WP is used, it is redirected to UC- per
> +		 * the default setup in  __cachemode2pte_tbl[].
> +		 */
> +		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> +		      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
> +	} else {
> +		/*
> +		 * WT is set to slot 7, which minimizes the risk of using

You say slot 7 here, but the title of the patch says slot 4?

> +		 * the PAT bit as slot 3 is UC and is currently unused.
> +		 * Slot 4 should remain as reserved.
> +		 *
> +		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-6:reserved, 7:WT
> +		 */
> +		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> +		      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, WT);
> +	}
>  
>  	/* Boot CPU check */
>  	if (!boot_pat_state)

Re: [PATCH v2 1/6] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Konrad Rzeszutek Wilk]

> -	/* Set PWT to Write-Combining. All other bits stay the same */
> -	/*
> -	 * PTE encoding used in Linux:
> -	 *      PAT
> -	 *      |PCD
> -	 *      ||PWT
> -	 *      |||
> -	 *      000 WB		_PAGE_CACHE_WB
> -	 *      001 WC		_PAGE_CACHE_WC
> -	 *      010 UC-		_PAGE_CACHE_UC_MINUS
> -	 *      011 UC		_PAGE_CACHE_UC


I think having this nice picture would be beneficial to folks
who want to understand it. And now you can of course expand it with
the slot 7 usage.

> -	 * PAT bit unused
> -	 */
> -	pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> -	      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
> +	if ((c->x86_vendor == X86_VENDOR_INTEL) &&
> +	    (((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
> +	     ((c->x86 == 0xf) && (c->x86_model <= 0x6)))) {
> +		/*
> +		 * Intel Pentium 2, 3, M, and 4 are affected by PAT errata,
> +		 * which makes the upper four entries unusable.  We do not
> +		 * use the upper four entries for all the affected processor
> +		 * families for safe.
> +		 *
> +		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-7:unusable
> +		 *
> +		 * NOTE: When WT or WP is used, it is redirected to UC- per
> +		 * the default setup in  __cachemode2pte_tbl[].
> +		 */
> +		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> +		      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
> +	} else {
> +		/*
> +		 * WT is set to slot 7, which minimizes the risk of using

You say slot 7 here, but the title of the patch says slot 4?

> +		 * the PAT bit as slot 3 is UC and is currently unused.
> +		 * Slot 4 should remain as reserved.
> +		 *
> +		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-6:reserved, 7:WT
> +		 */
> +		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> +		      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, WT);
> +	}
>  
>  	/* Boot CPU check */
>  	if (!boot_pat_state)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/6] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

On Fri, 2014-09-12 at 15:33 -0400, Konrad Rzeszutek Wilk wrote:
> > -	/* Set PWT to Write-Combining. All other bits stay the same */
> > -	/*
> > -	 * PTE encoding used in Linux:
> > -	 *      PAT
> > -	 *      |PCD
> > -	 *      ||PWT
> > -	 *      |||
> > -	 *      000 WB		_PAGE_CACHE_WB
> > -	 *      001 WC		_PAGE_CACHE_WC
> > -	 *      010 UC-		_PAGE_CACHE_UC_MINUS
> > -	 *      011 UC		_PAGE_CACHE_UC
> 
> 
> I think having this nice picture would be beneficial to folks
> who want to understand it. And now you can of course expand it with
> the slot 7 usage.

OK, I will try to preserve the picture.

> > -	 * PAT bit unused
> > -	 */
> > -	pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> > -	      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
> > +	if ((c->x86_vendor == X86_VENDOR_INTEL) &&
> > +	    (((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
> > +	     ((c->x86 == 0xf) && (c->x86_model <= 0x6)))) {
> > +		/*
> > +		 * Intel Pentium 2, 3, M, and 4 are affected by PAT errata,
> > +		 * which makes the upper four entries unusable.  We do not
> > +		 * use the upper four entries for all the affected processor
> > +		 * families for safe.
> > +		 *
> > +		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-7:unusable
> > +		 *
> > +		 * NOTE: When WT or WP is used, it is redirected to UC- per
> > +		 * the default setup in  __cachemode2pte_tbl[].
> > +		 */
> > +		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> > +		      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
> > +	} else {
> > +		/*
> > +		 * WT is set to slot 7, which minimizes the risk of using
> 
> You say slot 7 here, but the title of the patch says slot 4?

Oops! I will fix the title.

Thanks for reviewing!
-Toshi

Re: [PATCH v2 1/6] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

On Fri, 2014-09-12 at 15:33 -0400, Konrad Rzeszutek Wilk wrote:
> > -	/* Set PWT to Write-Combining. All other bits stay the same */
> > -	/*
> > -	 * PTE encoding used in Linux:
> > -	 *      PAT
> > -	 *      |PCD
> > -	 *      ||PWT
> > -	 *      |||
> > -	 *      000 WB		_PAGE_CACHE_WB
> > -	 *      001 WC		_PAGE_CACHE_WC
> > -	 *      010 UC-		_PAGE_CACHE_UC_MINUS
> > -	 *      011 UC		_PAGE_CACHE_UC
> 
> 
> I think having this nice picture would be beneficial to folks
> who want to understand it. And now you can of course expand it with
> the slot 7 usage.

OK, I will try to preserve the picture.

> > -	 * PAT bit unused
> > -	 */
> > -	pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> > -	      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
> > +	if ((c->x86_vendor == X86_VENDOR_INTEL) &&
> > +	    (((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
> > +	     ((c->x86 == 0xf) && (c->x86_model <= 0x6)))) {
> > +		/*
> > +		 * Intel Pentium 2, 3, M, and 4 are affected by PAT errata,
> > +		 * which makes the upper four entries unusable.  We do not
> > +		 * use the upper four entries for all the affected processor
> > +		 * families for safe.
> > +		 *
> > +		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-7:unusable
> > +		 *
> > +		 * NOTE: When WT or WP is used, it is redirected to UC- per
> > +		 * the default setup in  __cachemode2pte_tbl[].
> > +		 */
> > +		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> > +		      PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
> > +	} else {
> > +		/*
> > +		 * WT is set to slot 7, which minimizes the risk of using
> 
> You say slot 7 here, but the title of the patch says slot 4?

Oops! I will fix the title.

Thanks for reviewing!
-Toshi


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

This patch changes reserve_memtype() to handle the WT cache mode.
When PAT is not enabled, it continues to set UC- to *new_type for
any non-WB request.

When a target range is RAM, reserve_ram_pages_type() fails for WT
for now.  This function may not reserve a RAM range for WT since
reserve_ram_pages_type() uses the page flags limited to three memory
types, WB, WC and UC.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 arch/x86/include/asm/cacheflush.h |    4 ++++
 arch/x86/mm/pat.c                 |   16 +++++++++++++---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
index 157644b..c912680 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -53,6 +53,10 @@ static inline void set_page_memtype(struct page *pg,
 	case _PAGE_CACHE_MODE_WB:
 		memtype_flags = _PGMT_WB;
 		break;
+	case _PAGE_CACHE_MODE_WT:
+	case _PAGE_CACHE_MODE_WP:
+		pr_err("set_page_memtype: unsupported cachemode %d\n", memtype);
+		BUG();
 	default:
 		memtype_flags = _PGMT_DEFAULT;
 		break;
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 598d7c7..7644967 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -268,6 +268,8 @@ static int pat_pagerange_is_ram(resource_size_t start, resource_size_t end)
 
 /*
  * For RAM pages, we use page flags to mark the pages with appropriate type.
+ * The page flags are currently limited to three types, WB, WC and UC. Hence,
+ * any request to WT or WP will fail with -EINVAL.
  * Here we do two pass:
  * - Find the memtype of all the pages in the range, look for any conflicts
  * - In case of no conflicts, set the new memtype for pages in the range
@@ -279,6 +281,13 @@ static int reserve_ram_pages_type(u64 start, u64 end,
 	struct page *page;
 	u64 pfn;
 
+	if ((req_type == _PAGE_CACHE_MODE_WT) ||
+	    (req_type == _PAGE_CACHE_MODE_WP)) {
+		if (new_type)
+			*new_type = _PAGE_CACHE_MODE_UC_MINUS;
+		return -EINVAL;
+	}
+
 	if (req_type == _PAGE_CACHE_MODE_UC) {
 		/* We do not support strong UC */
 		WARN_ON_ONCE(1);
@@ -328,6 +337,7 @@ static int free_ram_pages_type(u64 start, u64 end)
  * - _PAGE_CACHE_MODE_WC
  * - _PAGE_CACHE_MODE_UC_MINUS
  * - _PAGE_CACHE_MODE_UC
+ * - _PAGE_CACHE_MODE_WT
  *
  * If new_type is NULL, function will return an error if it cannot reserve the
  * region with req_type. If new_type is non-NULL, function will return
@@ -347,10 +357,10 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type,
 	if (!pat_enabled) {
 		/* This is identical to page table setting without PAT */
 		if (new_type) {
-			if (req_type == _PAGE_CACHE_MODE_WC)
-				*new_type = _PAGE_CACHE_MODE_UC_MINUS;
+			if (req_type == _PAGE_CACHE_MODE_WB)
+				*new_type = _PAGE_CACHE_MODE_WB;
 			else
-				*new_type = req_type;
+				*new_type = _PAGE_CACHE_MODE_UC_MINUS;
 		}
 		return 0;
 	}

[PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

This patch changes reserve_memtype() to handle the WT cache mode.
When PAT is not enabled, it continues to set UC- to *new_type for
any non-WB request.

When a target range is RAM, reserve_ram_pages_type() fails for WT
for now.  This function may not reserve a RAM range for WT since
reserve_ram_pages_type() uses the page flags limited to three memory
types, WB, WC and UC.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 arch/x86/include/asm/cacheflush.h |    4 ++++
 arch/x86/mm/pat.c                 |   16 +++++++++++++---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
index 157644b..c912680 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -53,6 +53,10 @@ static inline void set_page_memtype(struct page *pg,
 	case _PAGE_CACHE_MODE_WB:
 		memtype_flags = _PGMT_WB;
 		break;
+	case _PAGE_CACHE_MODE_WT:
+	case _PAGE_CACHE_MODE_WP:
+		pr_err("set_page_memtype: unsupported cachemode %d\n", memtype);
+		BUG();
 	default:
 		memtype_flags = _PGMT_DEFAULT;
 		break;
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 598d7c7..7644967 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -268,6 +268,8 @@ static int pat_pagerange_is_ram(resource_size_t start, resource_size_t end)
 
 /*
  * For RAM pages, we use page flags to mark the pages with appropriate type.
+ * The page flags are currently limited to three types, WB, WC and UC. Hence,
+ * any request to WT or WP will fail with -EINVAL.
  * Here we do two pass:
  * - Find the memtype of all the pages in the range, look for any conflicts
  * - In case of no conflicts, set the new memtype for pages in the range
@@ -279,6 +281,13 @@ static int reserve_ram_pages_type(u64 start, u64 end,
 	struct page *page;
 	u64 pfn;
 
+	if ((req_type == _PAGE_CACHE_MODE_WT) ||
+	    (req_type == _PAGE_CACHE_MODE_WP)) {
+		if (new_type)
+			*new_type = _PAGE_CACHE_MODE_UC_MINUS;
+		return -EINVAL;
+	}
+
 	if (req_type == _PAGE_CACHE_MODE_UC) {
 		/* We do not support strong UC */
 		WARN_ON_ONCE(1);
@@ -328,6 +337,7 @@ static int free_ram_pages_type(u64 start, u64 end)
  * - _PAGE_CACHE_MODE_WC
  * - _PAGE_CACHE_MODE_UC_MINUS
  * - _PAGE_CACHE_MODE_UC
+ * - _PAGE_CACHE_MODE_WT
  *
  * If new_type is NULL, function will return an error if it cannot reserve the
  * region with req_type. If new_type is non-NULL, function will return
@@ -347,10 +357,10 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type,
 	if (!pat_enabled) {
 		/* This is identical to page table setting without PAT */
 		if (new_type) {
-			if (req_type == _PAGE_CACHE_MODE_WC)
-				*new_type = _PAGE_CACHE_MODE_UC_MINUS;
+			if (req_type == _PAGE_CACHE_MODE_WB)
+				*new_type = _PAGE_CACHE_MODE_WB;
 			else
-				*new_type = req_type;
+				*new_type = _PAGE_CACHE_MODE_UC_MINUS;
 		}
 		return 0;
 	}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> This patch changes reserve_memtype() to handle the WT cache mode.
> When PAT is not enabled, it continues to set UC- to *new_type for
> any non-WB request.
>
> When a target range is RAM, reserve_ram_pages_type() fails for WT
> for now.  This function may not reserve a RAM range for WT since
> reserve_ram_pages_type() uses the page flags limited to three memory
> types, WB, WC and UC.

Should it fail if WT is unavailable due to errata?  More generally,
how are all of the do_something_wc / do_something_wt /
do_something_nocache helpers supposed to handle unsupported types?

--Andy

>
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>
> ---
>  arch/x86/include/asm/cacheflush.h |    4 ++++
>  arch/x86/mm/pat.c                 |   16 +++++++++++++---
>  2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
> index 157644b..c912680 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -53,6 +53,10 @@ static inline void set_page_memtype(struct page *pg,
>         case _PAGE_CACHE_MODE_WB:
>                 memtype_flags = _PGMT_WB;
>                 break;
> +       case _PAGE_CACHE_MODE_WT:
> +       case _PAGE_CACHE_MODE_WP:
> +               pr_err("set_page_memtype: unsupported cachemode %d\n", memtype);
> +               BUG();
>         default:
>                 memtype_flags = _PGMT_DEFAULT;
>                 break;
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 598d7c7..7644967 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -268,6 +268,8 @@ static int pat_pagerange_is_ram(resource_size_t start, resource_size_t end)
>
>  /*
>   * For RAM pages, we use page flags to mark the pages with appropriate type.
> + * The page flags are currently limited to three types, WB, WC and UC. Hence,
> + * any request to WT or WP will fail with -EINVAL.
>   * Here we do two pass:
>   * - Find the memtype of all the pages in the range, look for any conflicts
>   * - In case of no conflicts, set the new memtype for pages in the range
> @@ -279,6 +281,13 @@ static int reserve_ram_pages_type(u64 start, u64 end,
>         struct page *page;
>         u64 pfn;
>
> +       if ((req_type == _PAGE_CACHE_MODE_WT) ||
> +           (req_type == _PAGE_CACHE_MODE_WP)) {
> +               if (new_type)
> +                       *new_type = _PAGE_CACHE_MODE_UC_MINUS;
> +               return -EINVAL;
> +       }
> +
>         if (req_type == _PAGE_CACHE_MODE_UC) {
>                 /* We do not support strong UC */
>                 WARN_ON_ONCE(1);
> @@ -328,6 +337,7 @@ static int free_ram_pages_type(u64 start, u64 end)
>   * - _PAGE_CACHE_MODE_WC
>   * - _PAGE_CACHE_MODE_UC_MINUS
>   * - _PAGE_CACHE_MODE_UC
> + * - _PAGE_CACHE_MODE_WT
>   *
>   * If new_type is NULL, function will return an error if it cannot reserve the
>   * region with req_type. If new_type is non-NULL, function will return
> @@ -347,10 +357,10 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type,
>         if (!pat_enabled) {
>                 /* This is identical to page table setting without PAT */
>                 if (new_type) {
> -                       if (req_type == _PAGE_CACHE_MODE_WC)
> -                               *new_type = _PAGE_CACHE_MODE_UC_MINUS;
> +                       if (req_type == _PAGE_CACHE_MODE_WB)
> +                               *new_type = _PAGE_CACHE_MODE_WB;
>                         else
> -                               *new_type = req_type;
> +                               *new_type = _PAGE_CACHE_MODE_UC_MINUS;
>                 }
>                 return 0;
>         }



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> This patch changes reserve_memtype() to handle the WT cache mode.
> When PAT is not enabled, it continues to set UC- to *new_type for
> any non-WB request.
>
> When a target range is RAM, reserve_ram_pages_type() fails for WT
> for now.  This function may not reserve a RAM range for WT since
> reserve_ram_pages_type() uses the page flags limited to three memory
> types, WB, WC and UC.

Should it fail if WT is unavailable due to errata?  More generally,
how are all of the do_something_wc / do_something_wt /
do_something_nocache helpers supposed to handle unsupported types?

--Andy

>
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>
> ---
>  arch/x86/include/asm/cacheflush.h |    4 ++++
>  arch/x86/mm/pat.c                 |   16 +++++++++++++---
>  2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
> index 157644b..c912680 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -53,6 +53,10 @@ static inline void set_page_memtype(struct page *pg,
>         case _PAGE_CACHE_MODE_WB:
>                 memtype_flags = _PGMT_WB;
>                 break;
> +       case _PAGE_CACHE_MODE_WT:
> +       case _PAGE_CACHE_MODE_WP:
> +               pr_err("set_page_memtype: unsupported cachemode %d\n", memtype);
> +               BUG();
>         default:
>                 memtype_flags = _PGMT_DEFAULT;
>                 break;
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 598d7c7..7644967 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -268,6 +268,8 @@ static int pat_pagerange_is_ram(resource_size_t start, resource_size_t end)
>
>  /*
>   * For RAM pages, we use page flags to mark the pages with appropriate type.
> + * The page flags are currently limited to three types, WB, WC and UC. Hence,
> + * any request to WT or WP will fail with -EINVAL.
>   * Here we do two pass:
>   * - Find the memtype of all the pages in the range, look for any conflicts
>   * - In case of no conflicts, set the new memtype for pages in the range
> @@ -279,6 +281,13 @@ static int reserve_ram_pages_type(u64 start, u64 end,
>         struct page *page;
>         u64 pfn;
>
> +       if ((req_type == _PAGE_CACHE_MODE_WT) ||
> +           (req_type == _PAGE_CACHE_MODE_WP)) {
> +               if (new_type)
> +                       *new_type = _PAGE_CACHE_MODE_UC_MINUS;
> +               return -EINVAL;
> +       }
> +
>         if (req_type == _PAGE_CACHE_MODE_UC) {
>                 /* We do not support strong UC */
>                 WARN_ON_ONCE(1);
> @@ -328,6 +337,7 @@ static int free_ram_pages_type(u64 start, u64 end)
>   * - _PAGE_CACHE_MODE_WC
>   * - _PAGE_CACHE_MODE_UC_MINUS
>   * - _PAGE_CACHE_MODE_UC
> + * - _PAGE_CACHE_MODE_WT
>   *
>   * If new_type is NULL, function will return an error if it cannot reserve the
>   * region with req_type. If new_type is non-NULL, function will return
> @@ -347,10 +357,10 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type,
>         if (!pat_enabled) {
>                 /* This is identical to page table setting without PAT */
>                 if (new_type) {
> -                       if (req_type == _PAGE_CACHE_MODE_WC)
> -                               *new_type = _PAGE_CACHE_MODE_UC_MINUS;
> +                       if (req_type == _PAGE_CACHE_MODE_WB)
> +                               *new_type = _PAGE_CACHE_MODE_WB;
>                         else
> -                               *new_type = req_type;
> +                               *new_type = _PAGE_CACHE_MODE_UC_MINUS;
>                 }
>                 return 0;
>         }



-- 
Andy Lutomirski
AMA Capital Management, LLC

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[H. Peter Anvin]

On 09/10/2014 11:26 AM, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>> This patch changes reserve_memtype() to handle the WT cache mode.
>> When PAT is not enabled, it continues to set UC- to *new_type for
>> any non-WB request.
>>
>> When a target range is RAM, reserve_ram_pages_type() fails for WT
>> for now.  This function may not reserve a RAM range for WT since
>> reserve_ram_pages_type() uses the page flags limited to three memory
>> types, WB, WC and UC.
> 
> Should it fail if WT is unavailable due to errata?  More generally,
> how are all of the do_something_wc / do_something_wt /
> do_something_nocache helpers supposed to handle unsupported types?
> 

Errata, or because it is pre-PAT hardware.  Keep in mind that even
pre-PAT hardware supports using page tables for cache types, it is only
that the only types supposed are WB, WT, UC.

	-hpa

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[H. Peter Anvin]

On 09/10/2014 11:26 AM, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>> This patch changes reserve_memtype() to handle the WT cache mode.
>> When PAT is not enabled, it continues to set UC- to *new_type for
>> any non-WB request.
>>
>> When a target range is RAM, reserve_ram_pages_type() fails for WT
>> for now.  This function may not reserve a RAM range for WT since
>> reserve_ram_pages_type() uses the page flags limited to three memory
>> types, WB, WC and UC.
> 
> Should it fail if WT is unavailable due to errata?  More generally,
> how are all of the do_something_wc / do_something_wt /
> do_something_nocache helpers supposed to handle unsupported types?
> 

Errata, or because it is pre-PAT hardware.  Keep in mind that even
pre-PAT hardware supports using page tables for cache types, it is only
that the only types supposed are WB, WT, UC.

	-hpa


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 11:26 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> > This patch changes reserve_memtype() to handle the WT cache mode.
> > When PAT is not enabled, it continues to set UC- to *new_type for
> > any non-WB request.
> >
> > When a target range is RAM, reserve_ram_pages_type() fails for WT
> > for now.  This function may not reserve a RAM range for WT since
> > reserve_ram_pages_type() uses the page flags limited to three memory
> > types, WB, WC and UC.
> 
> Should it fail if WT is unavailable due to errata?  More generally,
> how are all of the do_something_wc / do_something_wt /
> do_something_nocache helpers supposed to handle unsupported types?

When WT is unavailable due to the PAT errata, it does not fail but gets
redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
to UC- as well.

The failure case above is a run-time error when WT is enabled and is
targeted to RAM.  In this case, reserve_memtype() fails and sets UC- to
*new_type due to the limitation in page tables.  set_memory_xzy()
interfaces do not retry with new_type, but return an error.  I think
this makes sense since the caller should receive this error as this case
is a bug in the code (while running it on an old system is not a bug).

Thanks,
-Toshi

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 11:26 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> > This patch changes reserve_memtype() to handle the WT cache mode.
> > When PAT is not enabled, it continues to set UC- to *new_type for
> > any non-WB request.
> >
> > When a target range is RAM, reserve_ram_pages_type() fails for WT
> > for now.  This function may not reserve a RAM range for WT since
> > reserve_ram_pages_type() uses the page flags limited to three memory
> > types, WB, WC and UC.
> 
> Should it fail if WT is unavailable due to errata?  More generally,
> how are all of the do_something_wc / do_something_wt /
> do_something_nocache helpers supposed to handle unsupported types?

When WT is unavailable due to the PAT errata, it does not fail but gets
redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
to UC- as well.

The failure case above is a run-time error when WT is enabled and is
targeted to RAM.  In this case, reserve_memtype() fails and sets UC- to
*new_type due to the limitation in page tables.  set_memory_xzy()
interfaces do not retry with new_type, but return an error.  I think
this makes sense since the caller should receive this error as this case
is a bug in the code (while running it on an old system is not a bug).

Thanks,
-Toshi


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[H. Peter Anvin]

On 09/10/2014 12:30 PM, Toshi Kani wrote:
> 
> When WT is unavailable due to the PAT errata, it does not fail but gets
> redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
> to UC- as well.
> 

But on pre-PAT hardware you can still do WT.

	-hpa

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[H. Peter Anvin]

On 09/10/2014 12:30 PM, Toshi Kani wrote:
> 
> When WT is unavailable due to the PAT errata, it does not fail but gets
> redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
> to UC- as well.
> 

But on pre-PAT hardware you can still do WT.

	-hpa

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 13:14 -0700, H. Peter Anvin wrote:
> On 09/10/2014 12:30 PM, Toshi Kani wrote:
> > 
> > When WT is unavailable due to the PAT errata, it does not fail but gets
> > redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
> > to UC- as well.
> > 
> 
> But on pre-PAT hardware you can still do WT.

Yes, if we manipulates the bits directly, but such code is no longer
allowed for PAT systems.  The PAT-based kernel interfaces won't work for
pre-PAT systems, and therefore requests are redirected to UC- on such
systems. 

Thanks,
-Toshi

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 13:14 -0700, H. Peter Anvin wrote:
> On 09/10/2014 12:30 PM, Toshi Kani wrote:
> > 
> > When WT is unavailable due to the PAT errata, it does not fail but gets
> > redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
> > to UC- as well.
> > 
> 
> But on pre-PAT hardware you can still do WT.

Yes, if we manipulates the bits directly, but such code is no longer
allowed for PAT systems.  The PAT-based kernel interfaces won't work for
pre-PAT systems, and therefore requests are redirected to UC- on such
systems. 

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 1:30 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Wed, 2014-09-10 at 13:14 -0700, H. Peter Anvin wrote:
>> On 09/10/2014 12:30 PM, Toshi Kani wrote:
>> >
>> > When WT is unavailable due to the PAT errata, it does not fail but gets
>> > redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
>> > to UC- as well.
>> >
>>
>> But on pre-PAT hardware you can still do WT.
>
> Yes, if we manipulates the bits directly, but such code is no longer
> allowed for PAT systems.  The PAT-based kernel interfaces won't work for
> pre-PAT systems, and therefore requests are redirected to UC- on such
> systems.
>

Right, the PWT bit.  Forgot about that.

I wonder whether it would make sense to do some followup patches to
replace the current support for non-PAT machines with a "PAT" and
corresponding reverse map that exactly matches the mapping when PAT is
disabled.  These patches are almost there.

--Andy

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 1:30 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Wed, 2014-09-10 at 13:14 -0700, H. Peter Anvin wrote:
>> On 09/10/2014 12:30 PM, Toshi Kani wrote:
>> >
>> > When WT is unavailable due to the PAT errata, it does not fail but gets
>> > redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
>> > to UC- as well.
>> >
>>
>> But on pre-PAT hardware you can still do WT.
>
> Yes, if we manipulates the bits directly, but such code is no longer
> allowed for PAT systems.  The PAT-based kernel interfaces won't work for
> pre-PAT systems, and therefore requests are redirected to UC- on such
> systems.
>

Right, the PWT bit.  Forgot about that.

I wonder whether it would make sense to do some followup patches to
replace the current support for non-PAT machines with a "PAT" and
corresponding reverse map that exactly matches the mapping when PAT is
disabled.  These patches are almost there.

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 14:06 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 1:30 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Wed, 2014-09-10 at 13:14 -0700, H. Peter Anvin wrote:
> >> On 09/10/2014 12:30 PM, Toshi Kani wrote:
> >> >
> >> > When WT is unavailable due to the PAT errata, it does not fail but gets
> >> > redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
> >> > to UC- as well.
> >> >
> >>
> >> But on pre-PAT hardware you can still do WT.
> >
> > Yes, if we manipulates the bits directly, but such code is no longer
> > allowed for PAT systems.  The PAT-based kernel interfaces won't work for
> > pre-PAT systems, and therefore requests are redirected to UC- on such
> > systems.
> >
> 
> Right, the PWT bit.  Forgot about that.
> 
> I wonder whether it would make sense to do some followup patches to
> replace the current support for non-PAT machines with a "PAT" and
> corresponding reverse map that exactly matches the mapping when PAT is
> disabled.  These patches are almost there.

That's possible, but the only benefit is that we can enable WT on
pre-PAT systems, which I do not think anyone cares now...  WB & UC work
on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
reasonable.

Thanks,
-Toshi

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 14:06 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 1:30 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Wed, 2014-09-10 at 13:14 -0700, H. Peter Anvin wrote:
> >> On 09/10/2014 12:30 PM, Toshi Kani wrote:
> >> >
> >> > When WT is unavailable due to the PAT errata, it does not fail but gets
> >> > redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
> >> > to UC- as well.
> >> >
> >>
> >> But on pre-PAT hardware you can still do WT.
> >
> > Yes, if we manipulates the bits directly, but such code is no longer
> > allowed for PAT systems.  The PAT-based kernel interfaces won't work for
> > pre-PAT systems, and therefore requests are redirected to UC- on such
> > systems.
> >
> 
> Right, the PWT bit.  Forgot about that.
> 
> I wonder whether it would make sense to do some followup patches to
> replace the current support for non-PAT machines with a "PAT" and
> corresponding reverse map that exactly matches the mapping when PAT is
> disabled.  These patches are almost there.

That's possible, but the only benefit is that we can enable WT on
pre-PAT systems, which I do not think anyone cares now...  WB & UC work
on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
reasonable.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 2:11 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Wed, 2014-09-10 at 14:06 -0700, Andy Lutomirski wrote:
>> On Wed, Sep 10, 2014 at 1:30 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > On Wed, 2014-09-10 at 13:14 -0700, H. Peter Anvin wrote:
>> >> On 09/10/2014 12:30 PM, Toshi Kani wrote:
>> >> >
>> >> > When WT is unavailable due to the PAT errata, it does not fail but gets
>> >> > redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
>> >> > to UC- as well.
>> >> >
>> >>
>> >> But on pre-PAT hardware you can still do WT.
>> >
>> > Yes, if we manipulates the bits directly, but such code is no longer
>> > allowed for PAT systems.  The PAT-based kernel interfaces won't work for
>> > pre-PAT systems, and therefore requests are redirected to UC- on such
>> > systems.
>> >
>>
>> Right, the PWT bit.  Forgot about that.
>>
>> I wonder whether it would make sense to do some followup patches to
>> replace the current support for non-PAT machines with a "PAT" and
>> corresponding reverse map that exactly matches the mapping when PAT is
>> disabled.  These patches are almost there.
>
> That's possible, but the only benefit is that we can enable WT on
> pre-PAT systems, which I do not think anyone cares now...  WB & UC work
> on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
> reasonable.

It might end up being a cleanup, though.  A whole bunch of
rarely-exercised if (!pat_enabled) things would go away.

--Andy

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 2:11 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Wed, 2014-09-10 at 14:06 -0700, Andy Lutomirski wrote:
>> On Wed, Sep 10, 2014 at 1:30 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > On Wed, 2014-09-10 at 13:14 -0700, H. Peter Anvin wrote:
>> >> On 09/10/2014 12:30 PM, Toshi Kani wrote:
>> >> >
>> >> > When WT is unavailable due to the PAT errata, it does not fail but gets
>> >> > redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
>> >> > to UC- as well.
>> >> >
>> >>
>> >> But on pre-PAT hardware you can still do WT.
>> >
>> > Yes, if we manipulates the bits directly, but such code is no longer
>> > allowed for PAT systems.  The PAT-based kernel interfaces won't work for
>> > pre-PAT systems, and therefore requests are redirected to UC- on such
>> > systems.
>> >
>>
>> Right, the PWT bit.  Forgot about that.
>>
>> I wonder whether it would make sense to do some followup patches to
>> replace the current support for non-PAT machines with a "PAT" and
>> corresponding reverse map that exactly matches the mapping when PAT is
>> disabled.  These patches are almost there.
>
> That's possible, but the only benefit is that we can enable WT on
> pre-PAT systems, which I do not think anyone cares now...  WB & UC work
> on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
> reasonable.

It might end up being a cleanup, though.  A whole bunch of
rarely-exercised if (!pat_enabled) things would go away.

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 14:27 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 2:11 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Wed, 2014-09-10 at 14:06 -0700, Andy Lutomirski wrote:
> >> On Wed, Sep 10, 2014 at 1:30 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > On Wed, 2014-09-10 at 13:14 -0700, H. Peter Anvin wrote:
> >> >> On 09/10/2014 12:30 PM, Toshi Kani wrote:
> >> >> >
> >> >> > When WT is unavailable due to the PAT errata, it does not fail but gets
> >> >> > redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
> >> >> > to UC- as well.
> >> >> >
> >> >>
> >> >> But on pre-PAT hardware you can still do WT.
> >> >
> >> > Yes, if we manipulates the bits directly, but such code is no longer
> >> > allowed for PAT systems.  The PAT-based kernel interfaces won't work for
> >> > pre-PAT systems, and therefore requests are redirected to UC- on such
> >> > systems.
> >> >
> >>
> >> Right, the PWT bit.  Forgot about that.
> >>
> >> I wonder whether it would make sense to do some followup patches to
> >> replace the current support for non-PAT machines with a "PAT" and
> >> corresponding reverse map that exactly matches the mapping when PAT is
> >> disabled.  These patches are almost there.
> >
> > That's possible, but the only benefit is that we can enable WT on
> > pre-PAT systems, which I do not think anyone cares now...  WB & UC work
> > on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
> > reasonable.
> 
> It might end up being a cleanup, though.  A whole bunch of
> rarely-exercised if (!pat_enabled) things would go away.

Good point.  I will work on it. 

Thanks,
-Toshi

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 14:27 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 2:11 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Wed, 2014-09-10 at 14:06 -0700, Andy Lutomirski wrote:
> >> On Wed, Sep 10, 2014 at 1:30 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > On Wed, 2014-09-10 at 13:14 -0700, H. Peter Anvin wrote:
> >> >> On 09/10/2014 12:30 PM, Toshi Kani wrote:
> >> >> >
> >> >> > When WT is unavailable due to the PAT errata, it does not fail but gets
> >> >> > redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
> >> >> > to UC- as well.
> >> >> >
> >> >>
> >> >> But on pre-PAT hardware you can still do WT.
> >> >
> >> > Yes, if we manipulates the bits directly, but such code is no longer
> >> > allowed for PAT systems.  The PAT-based kernel interfaces won't work for
> >> > pre-PAT systems, and therefore requests are redirected to UC- on such
> >> > systems.
> >> >
> >>
> >> Right, the PWT bit.  Forgot about that.
> >>
> >> I wonder whether it would make sense to do some followup patches to
> >> replace the current support for non-PAT machines with a "PAT" and
> >> corresponding reverse map that exactly matches the mapping when PAT is
> >> disabled.  These patches are almost there.
> >
> > That's possible, but the only benefit is that we can enable WT on
> > pre-PAT systems, which I do not think anyone cares now...  WB & UC work
> > on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
> > reasonable.
> 
> It might end up being a cleanup, though.  A whole bunch of
> rarely-exercised if (!pat_enabled) things would go away.

Good point.  I will work on it. 

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[H. Peter Anvin]

On 09/10/2014 02:27 PM, Andy Lutomirski wrote:
>>
>> That's possible, but the only benefit is that we can enable WT on
>> pre-PAT systems, which I do not think anyone cares now...  WB & UC work
>> on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
>> reasonable.
> 
> It might end up being a cleanup, though.  A whole bunch of
> rarely-exercised if (!pat_enabled) things would go away.
> 

Yes.  Don't think of it as PAT vs non-PAT.  Think of it as a specific
set of cache types available on different processors.  The fact that you
may have to frob an MSR to initialize it is almost trivial in comparison.

	-hpa

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[H. Peter Anvin]

On 09/10/2014 02:27 PM, Andy Lutomirski wrote:
>>
>> That's possible, but the only benefit is that we can enable WT on
>> pre-PAT systems, which I do not think anyone cares now...  WB & UC work
>> on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
>> reasonable.
> 
> It might end up being a cleanup, though.  A whole bunch of
> rarely-exercised if (!pat_enabled) things would go away.
> 

Yes.  Don't think of it as PAT vs non-PAT.  Think of it as a specific
set of cache types available on different processors.  The fact that you
may have to frob an MSR to initialize it is almost trivial in comparison.

	-hpa


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 14:39 -0700, H. Peter Anvin wrote:
> On 09/10/2014 02:27 PM, Andy Lutomirski wrote:
> >>
> >> That's possible, but the only benefit is that we can enable WT on
> >> pre-PAT systems, which I do not think anyone cares now...  WB & UC work
> >> on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
> >> reasonable.
> > 
> > It might end up being a cleanup, though.  A whole bunch of
> > rarely-exercised if (!pat_enabled) things would go away.
> > 
> 
> Yes.  Don't think of it as PAT vs non-PAT.  Think of it as a specific
> set of cache types available on different processors.  The fact that you
> may have to frob an MSR to initialize it is almost trivial in comparison.

Right.

Thanks,
-Toshi

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 14:39 -0700, H. Peter Anvin wrote:
> On 09/10/2014 02:27 PM, Andy Lutomirski wrote:
> >>
> >> That's possible, but the only benefit is that we can enable WT on
> >> pre-PAT systems, which I do not think anyone cares now...  WB & UC work
> >> on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
> >> reasonable.
> > 
> > It might end up being a cleanup, though.  A whole bunch of
> > rarely-exercised if (!pat_enabled) things would go away.
> > 
> 
> Yes.  Don't think of it as PAT vs non-PAT.  Think of it as a specific
> set of cache types available on different processors.  The fact that you
> may have to frob an MSR to initialize it is almost trivial in comparison.

Right.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[H. Peter Anvin]

On 09/10/2014 02:47 PM, Toshi Kani wrote:
>>
>> Yes.  Don't think of it as PAT vs non-PAT.  Think of it as a specific
>> set of cache types available on different processors.  The fact that you
>> may have to frob an MSR to initialize it is almost trivial in comparison.
> 
> Right.
> 

In that sense the Xen "fixed PAT" fits right in.

	-hpa

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[H. Peter Anvin]

On 09/10/2014 02:47 PM, Toshi Kani wrote:
>>
>> Yes.  Don't think of it as PAT vs non-PAT.  Think of it as a specific
>> set of cache types available on different processors.  The fact that you
>> may have to frob an MSR to initialize it is almost trivial in comparison.
> 
> Right.
> 

In that sense the Xen "fixed PAT" fits right in.

	-hpa


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 15:00 -0700, H. Peter Anvin wrote:
> On 09/10/2014 02:47 PM, Toshi Kani wrote:
> >>
> >> Yes.  Don't think of it as PAT vs non-PAT.  Think of it as a specific
> >> set of cache types available on different processors.  The fact that you
> >> may have to frob an MSR to initialize it is almost trivial in comparison.
> > 
> > Right.
> > 
> 
> In that sense the Xen "fixed PAT" fits right in.

Got it. Nicely simplified. :) 

Thanks,
-Toshi

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Toshi Kani]

On Wed, 2014-09-10 at 15:00 -0700, H. Peter Anvin wrote:
> On 09/10/2014 02:47 PM, Toshi Kani wrote:
> >>
> >> Yes.  Don't think of it as PAT vs non-PAT.  Think of it as a specific
> >> set of cache types available on different processors.  The fact that you
> >> may have to frob an MSR to initialize it is almost trivial in comparison.
> > 
> > Right.
> > 
> 
> In that sense the Xen "fixed PAT" fits right in.

Got it. Nicely simplified. :) 

Thanks,
-Toshi


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[H. Peter Anvin]

On 09/10/2014 02:27 PM, Andy Lutomirski wrote:
>>
>> That's possible, but the only benefit is that we can enable WT on
>> pre-PAT systems, which I do not think anyone cares now...  WB & UC work
>> on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
>> reasonable.
> 
> It might end up being a cleanup, though.  A whole bunch of
> rarely-exercised if (!pat_enabled) things would go away.
> 

Yes.  Don't think of it as PAT vs non-PAT.  Think of it as a specific
set of cache types available on different processors.  The fact that you
may have to frob an MSR to initialize it is almost trivial in comparison.

	-hpa

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[H. Peter Anvin]

On 09/10/2014 02:27 PM, Andy Lutomirski wrote:
>>
>> That's possible, but the only benefit is that we can enable WT on
>> pre-PAT systems, which I do not think anyone cares now...  WB & UC work
>> on pre-PAT systems.  WC & WT need PAT.  I think this requirement is
>> reasonable.
> 
> It might end up being a cleanup, though.  A whole bunch of
> rarely-exercised if (!pat_enabled) things would go away.
> 

Yes.  Don't think of it as PAT vs non-PAT.  Think of it as a specific
set of cache types available on different processors.  The fact that you
may have to frob an MSR to initialize it is almost trivial in comparison.

	-hpa


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 1:14 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 09/10/2014 12:30 PM, Toshi Kani wrote:
>>
>> When WT is unavailable due to the PAT errata, it does not fail but gets
>> redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
>> to UC- as well.
>>
>
> But on pre-PAT hardware you can still do WT.
>

Using MTRRs?  /me shudders, although I suppose this would be okay for
NV-DIMMs as long as you map the whole thing WT.

One of these days I'll finish excising mtrr_add from everything
outside arch/x86.  I already killed it in all modern graphics drivers
:)

--Andy



>         -hpa
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 1:14 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 09/10/2014 12:30 PM, Toshi Kani wrote:
>>
>> When WT is unavailable due to the PAT errata, it does not fail but gets
>> redirected to UC-.  Similarly, when PAT is disabled, WT gets redirected
>> to UC- as well.
>>
>
> But on pre-PAT hardware you can still do WT.
>

Using MTRRs?  /me shudders, although I suppose this would be okay for
NV-DIMMs as long as you map the whole thing WT.

One of these days I'll finish excising mtrr_add from everything
outside arch/x86.  I already killed it in all modern graphics drivers
:)

--Andy



>         -hpa
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Konrad Rzeszutek Wilk]

On Wed, Sep 10, 2014 at 10:51:46AM -0600, Toshi Kani wrote:
> This patch changes reserve_memtype() to handle the WT cache mode.
> When PAT is not enabled, it continues to set UC- to *new_type for
> any non-WB request.
> 
> When a target range is RAM, reserve_ram_pages_type() fails for WT
> for now.  This function may not reserve a RAM range for WT since
> reserve_ram_pages_type() uses the page flags limited to three memory
> types, WB, WC and UC.
> 
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/include/asm/cacheflush.h |    4 ++++
>  arch/x86/mm/pat.c                 |   16 +++++++++++++---
>  2 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
> index 157644b..c912680 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -53,6 +53,10 @@ static inline void set_page_memtype(struct page *pg,
>  	case _PAGE_CACHE_MODE_WB:
>  		memtype_flags = _PGMT_WB;
>  		break;
> +	case _PAGE_CACHE_MODE_WT:
> +	case _PAGE_CACHE_MODE_WP:
> +		pr_err("set_page_memtype: unsupported cachemode %d\n", memtype);
> +		BUG();
>  	default:
>  		memtype_flags = _PGMT_DEFAULT;
>  		break;
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 598d7c7..7644967 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -268,6 +268,8 @@ static int pat_pagerange_is_ram(resource_size_t start, resource_size_t end)
>  
>  /*
>   * For RAM pages, we use page flags to mark the pages with appropriate type.
> + * The page flags are currently limited to three types, WB, WC and UC. Hence,
> + * any request to WT or WP will fail with -EINVAL.
>   * Here we do two pass:
>   * - Find the memtype of all the pages in the range, look for any conflicts
>   * - In case of no conflicts, set the new memtype for pages in the range
> @@ -279,6 +281,13 @@ static int reserve_ram_pages_type(u64 start, u64 end,
>  	struct page *page;
>  	u64 pfn;
>  
> +	if ((req_type == _PAGE_CACHE_MODE_WT) ||
> +	    (req_type == _PAGE_CACHE_MODE_WP)) {
> +		if (new_type)
> +			*new_type = _PAGE_CACHE_MODE_UC_MINUS;
> +		return -EINVAL;
> +	}
> +
>  	if (req_type == _PAGE_CACHE_MODE_UC) {
>  		/* We do not support strong UC */
>  		WARN_ON_ONCE(1);
> @@ -328,6 +337,7 @@ static int free_ram_pages_type(u64 start, u64 end)
>   * - _PAGE_CACHE_MODE_WC
>   * - _PAGE_CACHE_MODE_UC_MINUS
>   * - _PAGE_CACHE_MODE_UC
> + * - _PAGE_CACHE_MODE_WT
>   *
>   * If new_type is NULL, function will return an error if it cannot reserve the
>   * region with req_type. If new_type is non-NULL, function will return
> @@ -347,10 +357,10 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type,
>  	if (!pat_enabled) {
>  		/* This is identical to page table setting without PAT */
>  		if (new_type) {
> -			if (req_type == _PAGE_CACHE_MODE_WC)
> -				*new_type = _PAGE_CACHE_MODE_UC_MINUS;
> +			if (req_type == _PAGE_CACHE_MODE_WB)
> +				*new_type = _PAGE_CACHE_MODE_WB;
>  			else
> -				*new_type = req_type;
> +				*new_type = _PAGE_CACHE_MODE_UC_MINUS;
>  		}
>  		return 0;
>  	}

Re: [PATCH v2 2/6] x86, mm, pat: Change reserve_memtype() to handle WT

[Konrad Rzeszutek Wilk]

On Wed, Sep 10, 2014 at 10:51:46AM -0600, Toshi Kani wrote:
> This patch changes reserve_memtype() to handle the WT cache mode.
> When PAT is not enabled, it continues to set UC- to *new_type for
> any non-WB request.
> 
> When a target range is RAM, reserve_ram_pages_type() fails for WT
> for now.  This function may not reserve a RAM range for WT since
> reserve_ram_pages_type() uses the page flags limited to three memory
> types, WB, WC and UC.
> 
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/include/asm/cacheflush.h |    4 ++++
>  arch/x86/mm/pat.c                 |   16 +++++++++++++---
>  2 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
> index 157644b..c912680 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -53,6 +53,10 @@ static inline void set_page_memtype(struct page *pg,
>  	case _PAGE_CACHE_MODE_WB:
>  		memtype_flags = _PGMT_WB;
>  		break;
> +	case _PAGE_CACHE_MODE_WT:
> +	case _PAGE_CACHE_MODE_WP:
> +		pr_err("set_page_memtype: unsupported cachemode %d\n", memtype);
> +		BUG();
>  	default:
>  		memtype_flags = _PGMT_DEFAULT;
>  		break;
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 598d7c7..7644967 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -268,6 +268,8 @@ static int pat_pagerange_is_ram(resource_size_t start, resource_size_t end)
>  
>  /*
>   * For RAM pages, we use page flags to mark the pages with appropriate type.
> + * The page flags are currently limited to three types, WB, WC and UC. Hence,
> + * any request to WT or WP will fail with -EINVAL.
>   * Here we do two pass:
>   * - Find the memtype of all the pages in the range, look for any conflicts
>   * - In case of no conflicts, set the new memtype for pages in the range
> @@ -279,6 +281,13 @@ static int reserve_ram_pages_type(u64 start, u64 end,
>  	struct page *page;
>  	u64 pfn;
>  
> +	if ((req_type == _PAGE_CACHE_MODE_WT) ||
> +	    (req_type == _PAGE_CACHE_MODE_WP)) {
> +		if (new_type)
> +			*new_type = _PAGE_CACHE_MODE_UC_MINUS;
> +		return -EINVAL;
> +	}
> +
>  	if (req_type == _PAGE_CACHE_MODE_UC) {
>  		/* We do not support strong UC */
>  		WARN_ON_ONCE(1);
> @@ -328,6 +337,7 @@ static int free_ram_pages_type(u64 start, u64 end)
>   * - _PAGE_CACHE_MODE_WC
>   * - _PAGE_CACHE_MODE_UC_MINUS
>   * - _PAGE_CACHE_MODE_UC
> + * - _PAGE_CACHE_MODE_WT
>   *
>   * If new_type is NULL, function will return an error if it cannot reserve the
>   * region with req_type. If new_type is non-NULL, function will return
> @@ -347,10 +357,10 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type,
>  	if (!pat_enabled) {
>  		/* This is identical to page table setting without PAT */
>  		if (new_type) {
> -			if (req_type == _PAGE_CACHE_MODE_WC)
> -				*new_type = _PAGE_CACHE_MODE_UC_MINUS;
> +			if (req_type == _PAGE_CACHE_MODE_WB)
> +				*new_type = _PAGE_CACHE_MODE_WB;
>  			else
> -				*new_type = req_type;
> +				*new_type = _PAGE_CACHE_MODE_UC_MINUS;
>  		}
>  		return 0;
>  	}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH v2 3/6] x86, mm, asm-gen: Add ioremap_wt() for WT

[Toshi Kani]

This patch adds ioremap_wt() for creating WT mapping on x86.
It follows the same model as ioremap_wc() for multi-architecture
support.  ARCH_HAS_IOREMAP_WT is defined in the x86 version of
io.h to indicate that ioremap_wt() is implemented on x86.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 arch/x86/include/asm/io.h   |    2 ++
 arch/x86/mm/ioremap.c       |   24 ++++++++++++++++++++++++
 include/asm-generic/io.h    |    4 ++++
 include/asm-generic/iomap.h |    4 ++++
 4 files changed, 34 insertions(+)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 71b9e65..c813c86 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -35,6 +35,7 @@
   */
 
 #define ARCH_HAS_IOREMAP_WC
+#define ARCH_HAS_IOREMAP_WT
 
 #include <linux/string.h>
 #include <linux/compiler.h>
@@ -316,6 +317,7 @@ extern void unxlate_dev_mem_ptr(unsigned long phys, void *addr);
 extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
 				enum page_cache_mode pcm);
 extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
+extern void __iomem *ioremap_wt(resource_size_t offset, unsigned long size);
 
 extern bool is_early_ioremap_ptep(pte_t *ptep);
 
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 885fe44..952f4b4 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -155,6 +155,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 		prot = __pgprot(pgprot_val(prot) |
 				cachemode2protval(_PAGE_CACHE_MODE_WC));
 		break;
+	case _PAGE_CACHE_MODE_WT:
+		prot = __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_WT));
+		break;
 	case _PAGE_CACHE_MODE_WB:
 		break;
 	}
@@ -249,6 +253,26 @@ void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
 }
 EXPORT_SYMBOL(ioremap_wc);
 
+/**
+ * ioremap_wt	-	map memory into CPU space write through
+ * @phys_addr:	bus address of the memory
+ * @size:	size of the resource to map
+ *
+ * This version of ioremap ensures that the memory is marked write through.
+ * Write through writes data into memory while keeping the cache up-to-date.
+ *
+ * Must be freed with iounmap.
+ */
+void __iomem *ioremap_wt(resource_size_t phys_addr, unsigned long size)
+{
+	if (pat_enabled)
+		return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WT,
+					__builtin_return_address(0));
+	else
+		return ioremap_nocache(phys_addr, size);
+}
+EXPORT_SYMBOL(ioremap_wt);
+
 void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
 {
 	return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB,
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 975e1cc..405d418 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -322,6 +322,10 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
 #define ioremap_wc ioremap_nocache
 #endif
 
+#ifndef ioremap_wt
+#define ioremap_wt ioremap_nocache
+#endif
+
 static inline void iounmap(void __iomem *addr)
 {
 }
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 1b41011..d8f8622 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -66,6 +66,10 @@ extern void ioport_unmap(void __iomem *);
 #define ioremap_wc ioremap_nocache
 #endif
 
+#ifndef ARCH_HAS_IOREMAP_WT
+#define ioremap_wt ioremap_nocache
+#endif
+
 #ifdef CONFIG_PCI
 /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
 struct pci_dev;

[PATCH v2 3/6] x86, mm, asm-gen: Add ioremap_wt() for WT

[Toshi Kani]

This patch adds ioremap_wt() for creating WT mapping on x86.
It follows the same model as ioremap_wc() for multi-architecture
support.  ARCH_HAS_IOREMAP_WT is defined in the x86 version of
io.h to indicate that ioremap_wt() is implemented on x86.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 arch/x86/include/asm/io.h   |    2 ++
 arch/x86/mm/ioremap.c       |   24 ++++++++++++++++++++++++
 include/asm-generic/io.h    |    4 ++++
 include/asm-generic/iomap.h |    4 ++++
 4 files changed, 34 insertions(+)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 71b9e65..c813c86 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -35,6 +35,7 @@
   */
 
 #define ARCH_HAS_IOREMAP_WC
+#define ARCH_HAS_IOREMAP_WT
 
 #include <linux/string.h>
 #include <linux/compiler.h>
@@ -316,6 +317,7 @@ extern void unxlate_dev_mem_ptr(unsigned long phys, void *addr);
 extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
 				enum page_cache_mode pcm);
 extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
+extern void __iomem *ioremap_wt(resource_size_t offset, unsigned long size);
 
 extern bool is_early_ioremap_ptep(pte_t *ptep);
 
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 885fe44..952f4b4 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -155,6 +155,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 		prot = __pgprot(pgprot_val(prot) |
 				cachemode2protval(_PAGE_CACHE_MODE_WC));
 		break;
+	case _PAGE_CACHE_MODE_WT:
+		prot = __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_WT));
+		break;
 	case _PAGE_CACHE_MODE_WB:
 		break;
 	}
@@ -249,6 +253,26 @@ void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
 }
 EXPORT_SYMBOL(ioremap_wc);
 
+/**
+ * ioremap_wt	-	map memory into CPU space write through
+ * @phys_addr:	bus address of the memory
+ * @size:	size of the resource to map
+ *
+ * This version of ioremap ensures that the memory is marked write through.
+ * Write through writes data into memory while keeping the cache up-to-date.
+ *
+ * Must be freed with iounmap.
+ */
+void __iomem *ioremap_wt(resource_size_t phys_addr, unsigned long size)
+{
+	if (pat_enabled)
+		return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WT,
+					__builtin_return_address(0));
+	else
+		return ioremap_nocache(phys_addr, size);
+}
+EXPORT_SYMBOL(ioremap_wt);
+
 void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
 {
 	return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB,
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 975e1cc..405d418 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -322,6 +322,10 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
 #define ioremap_wc ioremap_nocache
 #endif
 
+#ifndef ioremap_wt
+#define ioremap_wt ioremap_nocache
+#endif
+
 static inline void iounmap(void __iomem *addr)
 {
 }
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 1b41011..d8f8622 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -66,6 +66,10 @@ extern void ioport_unmap(void __iomem *);
 #define ioremap_wc ioremap_nocache
 #endif
 
+#ifndef ARCH_HAS_IOREMAP_WT
+#define ioremap_wt ioremap_nocache
+#endif
+
 #ifdef CONFIG_PCI
 /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
 struct pci_dev;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 3/6] x86, mm, asm-gen: Add ioremap_wt() for WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> This patch adds ioremap_wt() for creating WT mapping on x86.
> It follows the same model as ioremap_wc() for multi-architecture
> support.  ARCH_HAS_IOREMAP_WT is defined in the x86 version of
> io.h to indicate that ioremap_wt() is implemented on x86.
>
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>
> ---
>  arch/x86/include/asm/io.h   |    2 ++
>  arch/x86/mm/ioremap.c       |   24 ++++++++++++++++++++++++
>  include/asm-generic/io.h    |    4 ++++
>  include/asm-generic/iomap.h |    4 ++++
>  4 files changed, 34 insertions(+)
>
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 71b9e65..c813c86 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -35,6 +35,7 @@
>    */
>
>  #define ARCH_HAS_IOREMAP_WC
> +#define ARCH_HAS_IOREMAP_WT
>
>  #include <linux/string.h>
>  #include <linux/compiler.h>
> @@ -316,6 +317,7 @@ extern void unxlate_dev_mem_ptr(unsigned long phys, void *addr);
>  extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
>                                 enum page_cache_mode pcm);
>  extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
> +extern void __iomem *ioremap_wt(resource_size_t offset, unsigned long size);
>
>  extern bool is_early_ioremap_ptep(pte_t *ptep);
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 885fe44..952f4b4 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -155,6 +155,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
>                 prot = __pgprot(pgprot_val(prot) |
>                                 cachemode2protval(_PAGE_CACHE_MODE_WC));
>                 break;
> +       case _PAGE_CACHE_MODE_WT:
> +               prot = __pgprot(pgprot_val(prot) |
> +                               cachemode2protval(_PAGE_CACHE_MODE_WT));
> +               break;
>         case _PAGE_CACHE_MODE_WB:
>                 break;
>         }
> @@ -249,6 +253,26 @@ void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
>  }
>  EXPORT_SYMBOL(ioremap_wc);
>
> +/**
> + * ioremap_wt  -       map memory into CPU space write through
> + * @phys_addr: bus address of the memory
> + * @size:      size of the resource to map
> + *
> + * This version of ioremap ensures that the memory is marked write through.
> + * Write through writes data into memory while keeping the cache up-to-date.
> + *
> + * Must be freed with iounmap.
> + */
> +void __iomem *ioremap_wt(resource_size_t phys_addr, unsigned long size)
> +{
> +       if (pat_enabled)
> +               return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WT,
> +                                       __builtin_return_address(0));
> +       else
> +               return ioremap_nocache(phys_addr, size);
> +}
> +EXPORT_SYMBOL(ioremap_wt);
> +
>  void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
>  {
>         return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB,
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 975e1cc..405d418 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -322,6 +322,10 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
>  #define ioremap_wc ioremap_nocache
>  #endif
>
> +#ifndef ioremap_wt
> +#define ioremap_wt ioremap_nocache
> +#endif
> +
>  static inline void iounmap(void __iomem *addr)
>  {
>  }
> diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> index 1b41011..d8f8622 100644
> --- a/include/asm-generic/iomap.h
> +++ b/include/asm-generic/iomap.h
> @@ -66,6 +66,10 @@ extern void ioport_unmap(void __iomem *);
>  #define ioremap_wc ioremap_nocache
>  #endif
>
> +#ifndef ARCH_HAS_IOREMAP_WT
> +#define ioremap_wt ioremap_nocache
> +#endif
> +

This is a little bit sad.  I wouldn't be too surprised if there are
eventually users who prefer WC or WB over UC if WT isn't available
(and they'll want a corresponding way to figure out what kind of fence
to use).

Hey Intel and AMD: want to add another memtype that has cacheable
reads but acts like WC for writes?  Being able to use sfence to flush
to NV-DIMMs would be neat!  (Presumably nontemporal stores to WT
memory work like that, but this stuff is barely documented.)

--Andy

Re: [PATCH v2 3/6] x86, mm, asm-gen: Add ioremap_wt() for WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> This patch adds ioremap_wt() for creating WT mapping on x86.
> It follows the same model as ioremap_wc() for multi-architecture
> support.  ARCH_HAS_IOREMAP_WT is defined in the x86 version of
> io.h to indicate that ioremap_wt() is implemented on x86.
>
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>
> ---
>  arch/x86/include/asm/io.h   |    2 ++
>  arch/x86/mm/ioremap.c       |   24 ++++++++++++++++++++++++
>  include/asm-generic/io.h    |    4 ++++
>  include/asm-generic/iomap.h |    4 ++++
>  4 files changed, 34 insertions(+)
>
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 71b9e65..c813c86 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -35,6 +35,7 @@
>    */
>
>  #define ARCH_HAS_IOREMAP_WC
> +#define ARCH_HAS_IOREMAP_WT
>
>  #include <linux/string.h>
>  #include <linux/compiler.h>
> @@ -316,6 +317,7 @@ extern void unxlate_dev_mem_ptr(unsigned long phys, void *addr);
>  extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
>                                 enum page_cache_mode pcm);
>  extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
> +extern void __iomem *ioremap_wt(resource_size_t offset, unsigned long size);
>
>  extern bool is_early_ioremap_ptep(pte_t *ptep);
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 885fe44..952f4b4 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -155,6 +155,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
>                 prot = __pgprot(pgprot_val(prot) |
>                                 cachemode2protval(_PAGE_CACHE_MODE_WC));
>                 break;
> +       case _PAGE_CACHE_MODE_WT:
> +               prot = __pgprot(pgprot_val(prot) |
> +                               cachemode2protval(_PAGE_CACHE_MODE_WT));
> +               break;
>         case _PAGE_CACHE_MODE_WB:
>                 break;
>         }
> @@ -249,6 +253,26 @@ void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
>  }
>  EXPORT_SYMBOL(ioremap_wc);
>
> +/**
> + * ioremap_wt  -       map memory into CPU space write through
> + * @phys_addr: bus address of the memory
> + * @size:      size of the resource to map
> + *
> + * This version of ioremap ensures that the memory is marked write through.
> + * Write through writes data into memory while keeping the cache up-to-date.
> + *
> + * Must be freed with iounmap.
> + */
> +void __iomem *ioremap_wt(resource_size_t phys_addr, unsigned long size)
> +{
> +       if (pat_enabled)
> +               return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WT,
> +                                       __builtin_return_address(0));
> +       else
> +               return ioremap_nocache(phys_addr, size);
> +}
> +EXPORT_SYMBOL(ioremap_wt);
> +
>  void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
>  {
>         return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB,
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 975e1cc..405d418 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -322,6 +322,10 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
>  #define ioremap_wc ioremap_nocache
>  #endif
>
> +#ifndef ioremap_wt
> +#define ioremap_wt ioremap_nocache
> +#endif
> +
>  static inline void iounmap(void __iomem *addr)
>  {
>  }
> diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> index 1b41011..d8f8622 100644
> --- a/include/asm-generic/iomap.h
> +++ b/include/asm-generic/iomap.h
> @@ -66,6 +66,10 @@ extern void ioport_unmap(void __iomem *);
>  #define ioremap_wc ioremap_nocache
>  #endif
>
> +#ifndef ARCH_HAS_IOREMAP_WT
> +#define ioremap_wt ioremap_nocache
> +#endif
> +

This is a little bit sad.  I wouldn't be too surprised if there are
eventually users who prefer WC or WB over UC if WT isn't available
(and they'll want a corresponding way to figure out what kind of fence
to use).

Hey Intel and AMD: want to add another memtype that has cacheable
reads but acts like WC for writes?  Being able to use sfence to flush
to NV-DIMMs would be neat!  (Presumably nontemporal stores to WT
memory work like that, but this stuff is barely documented.)

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 3/6] x86, mm, asm-gen: Add ioremap_wt() for WT

[Toshi Kani]

On Wed, 2014-09-10 at 11:29 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
 :
> > +#ifndef ARCH_HAS_IOREMAP_WT
> > +#define ioremap_wt ioremap_nocache
> > +#endif
> > +
> 
> This is a little bit sad.  I wouldn't be too surprised if there are
> eventually users who prefer WC or WB over UC if WT isn't available
> (and they'll want a corresponding way to figure out what kind of fence
> to use).

Right, this redirection is not ideal for the performance, but it is done
this way for the correctness.  WT & UC have strongly ordered writes, but
WB & WC do not.

Thanks,
-Toshi

Re: [PATCH v2 3/6] x86, mm, asm-gen: Add ioremap_wt() for WT

[Toshi Kani]

On Wed, 2014-09-10 at 11:29 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
 :
> > +#ifndef ARCH_HAS_IOREMAP_WT
> > +#define ioremap_wt ioremap_nocache
> > +#endif
> > +
> 
> This is a little bit sad.  I wouldn't be too surprised if there are
> eventually users who prefer WC or WB over UC if WT isn't available
> (and they'll want a corresponding way to figure out what kind of fence
> to use).

Right, this redirection is not ideal for the performance, but it is done
this way for the correctness.  WT & UC have strongly ordered writes, but
WB & WC do not.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 3/6] x86, mm, asm-gen: Add ioremap_wt() for WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 12:40 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Wed, 2014-09-10 at 11:29 -0700, Andy Lutomirski wrote:
>> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>  :
>> > +#ifndef ARCH_HAS_IOREMAP_WT
>> > +#define ioremap_wt ioremap_nocache
>> > +#endif
>> > +
>>
>> This is a little bit sad.  I wouldn't be too surprised if there are
>> eventually users who prefer WC or WB over UC if WT isn't available
>> (and they'll want a corresponding way to figure out what kind of fence
>> to use).
>
> Right, this redirection is not ideal for the performance, but it is done
> this way for the correctness.  WT & UC have strongly ordered writes, but
> WB & WC do not.

Fair enough.  I think that this is unlikely to ever matter on x86, but
it might if NV-DIMMs end up used on another architecture w/o WT (or on
Xen, perhaps).  Your code is certainly fine from a correctness POV.

Aside: WB writes are IIRC even more strongly ordered than WC.

>
> Thanks,
> -Toshi
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH v2 3/6] x86, mm, asm-gen: Add ioremap_wt() for WT

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 12:40 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Wed, 2014-09-10 at 11:29 -0700, Andy Lutomirski wrote:
>> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>  :
>> > +#ifndef ARCH_HAS_IOREMAP_WT
>> > +#define ioremap_wt ioremap_nocache
>> > +#endif
>> > +
>>
>> This is a little bit sad.  I wouldn't be too surprised if there are
>> eventually users who prefer WC or WB over UC if WT isn't available
>> (and they'll want a corresponding way to figure out what kind of fence
>> to use).
>
> Right, this redirection is not ideal for the performance, but it is done
> this way for the correctness.  WT & UC have strongly ordered writes, but
> WB & WC do not.

Fair enough.  I think that this is unlikely to ever matter on x86, but
it might if NV-DIMMs end up used on another architecture w/o WT (or on
Xen, perhaps).  Your code is certainly fine from a correctness POV.

Aside: WB writes are IIRC even more strongly ordered than WC.

>
> Thanks,
> -Toshi
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 3/6] x86, mm, asm-gen: Add ioremap_wt() for WT

[Konrad Rzeszutek Wilk]

On Wed, Sep 10, 2014 at 10:51:47AM -0600, Toshi Kani wrote:
> This patch adds ioremap_wt() for creating WT mapping on x86.
> It follows the same model as ioremap_wc() for multi-architecture
> support.  ARCH_HAS_IOREMAP_WT is defined in the x86 version of
> io.h to indicate that ioremap_wt() is implemented on x86.
> 
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> ---
>  arch/x86/include/asm/io.h   |    2 ++
>  arch/x86/mm/ioremap.c       |   24 ++++++++++++++++++++++++
>  include/asm-generic/io.h    |    4 ++++
>  include/asm-generic/iomap.h |    4 ++++
>  4 files changed, 34 insertions(+)
> 
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 71b9e65..c813c86 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -35,6 +35,7 @@
>    */
>  
>  #define ARCH_HAS_IOREMAP_WC
> +#define ARCH_HAS_IOREMAP_WT
>  
>  #include <linux/string.h>
>  #include <linux/compiler.h>
> @@ -316,6 +317,7 @@ extern void unxlate_dev_mem_ptr(unsigned long phys, void *addr);
>  extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
>  				enum page_cache_mode pcm);
>  extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
> +extern void __iomem *ioremap_wt(resource_size_t offset, unsigned long size);
>  
>  extern bool is_early_ioremap_ptep(pte_t *ptep);
>  
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 885fe44..952f4b4 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -155,6 +155,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
>  		prot = __pgprot(pgprot_val(prot) |
>  				cachemode2protval(_PAGE_CACHE_MODE_WC));
>  		break;
> +	case _PAGE_CACHE_MODE_WT:
> +		prot = __pgprot(pgprot_val(prot) |
> +				cachemode2protval(_PAGE_CACHE_MODE_WT));
> +		break;
>  	case _PAGE_CACHE_MODE_WB:
>  		break;
>  	}
> @@ -249,6 +253,26 @@ void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
>  }
>  EXPORT_SYMBOL(ioremap_wc);
>  
> +/**
> + * ioremap_wt	-	map memory into CPU space write through
> + * @phys_addr:	bus address of the memory
> + * @size:	size of the resource to map
> + *
> + * This version of ioremap ensures that the memory is marked write through.
> + * Write through writes data into memory while keeping the cache up-to-date.
> + *
> + * Must be freed with iounmap.
> + */
> +void __iomem *ioremap_wt(resource_size_t phys_addr, unsigned long size)
> +{
> +	if (pat_enabled)
> +		return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WT,
> +					__builtin_return_address(0));
> +	else
> +		return ioremap_nocache(phys_addr, size);
> +}
> +EXPORT_SYMBOL(ioremap_wt);
> +
>  void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
>  {
>  	return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB,
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 975e1cc..405d418 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -322,6 +322,10 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
>  #define ioremap_wc ioremap_nocache
>  #endif
>  
> +#ifndef ioremap_wt
> +#define ioremap_wt ioremap_nocache
> +#endif
> +
>  static inline void iounmap(void __iomem *addr)
>  {
>  }
> diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> index 1b41011..d8f8622 100644
> --- a/include/asm-generic/iomap.h
> +++ b/include/asm-generic/iomap.h
> @@ -66,6 +66,10 @@ extern void ioport_unmap(void __iomem *);
>  #define ioremap_wc ioremap_nocache
>  #endif
>  
> +#ifndef ARCH_HAS_IOREMAP_WT
> +#define ioremap_wt ioremap_nocache
> +#endif
> +
>  #ifdef CONFIG_PCI
>  /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
>  struct pci_dev;

Re: [PATCH v2 3/6] x86, mm, asm-gen: Add ioremap_wt() for WT

[Konrad Rzeszutek Wilk]

On Wed, Sep 10, 2014 at 10:51:47AM -0600, Toshi Kani wrote:
> This patch adds ioremap_wt() for creating WT mapping on x86.
> It follows the same model as ioremap_wc() for multi-architecture
> support.  ARCH_HAS_IOREMAP_WT is defined in the x86 version of
> io.h to indicate that ioremap_wt() is implemented on x86.
> 
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> ---
>  arch/x86/include/asm/io.h   |    2 ++
>  arch/x86/mm/ioremap.c       |   24 ++++++++++++++++++++++++
>  include/asm-generic/io.h    |    4 ++++
>  include/asm-generic/iomap.h |    4 ++++
>  4 files changed, 34 insertions(+)
> 
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 71b9e65..c813c86 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -35,6 +35,7 @@
>    */
>  
>  #define ARCH_HAS_IOREMAP_WC
> +#define ARCH_HAS_IOREMAP_WT
>  
>  #include <linux/string.h>
>  #include <linux/compiler.h>
> @@ -316,6 +317,7 @@ extern void unxlate_dev_mem_ptr(unsigned long phys, void *addr);
>  extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
>  				enum page_cache_mode pcm);
>  extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
> +extern void __iomem *ioremap_wt(resource_size_t offset, unsigned long size);
>  
>  extern bool is_early_ioremap_ptep(pte_t *ptep);
>  
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 885fe44..952f4b4 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -155,6 +155,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
>  		prot = __pgprot(pgprot_val(prot) |
>  				cachemode2protval(_PAGE_CACHE_MODE_WC));
>  		break;
> +	case _PAGE_CACHE_MODE_WT:
> +		prot = __pgprot(pgprot_val(prot) |
> +				cachemode2protval(_PAGE_CACHE_MODE_WT));
> +		break;
>  	case _PAGE_CACHE_MODE_WB:
>  		break;
>  	}
> @@ -249,6 +253,26 @@ void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
>  }
>  EXPORT_SYMBOL(ioremap_wc);
>  
> +/**
> + * ioremap_wt	-	map memory into CPU space write through
> + * @phys_addr:	bus address of the memory
> + * @size:	size of the resource to map
> + *
> + * This version of ioremap ensures that the memory is marked write through.
> + * Write through writes data into memory while keeping the cache up-to-date.
> + *
> + * Must be freed with iounmap.
> + */
> +void __iomem *ioremap_wt(resource_size_t phys_addr, unsigned long size)
> +{
> +	if (pat_enabled)
> +		return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WT,
> +					__builtin_return_address(0));
> +	else
> +		return ioremap_nocache(phys_addr, size);
> +}
> +EXPORT_SYMBOL(ioremap_wt);
> +
>  void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
>  {
>  	return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB,
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 975e1cc..405d418 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -322,6 +322,10 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
>  #define ioremap_wc ioremap_nocache
>  #endif
>  
> +#ifndef ioremap_wt
> +#define ioremap_wt ioremap_nocache
> +#endif
> +
>  static inline void iounmap(void __iomem *addr)
>  {
>  }
> diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> index 1b41011..d8f8622 100644
> --- a/include/asm-generic/iomap.h
> +++ b/include/asm-generic/iomap.h
> @@ -66,6 +66,10 @@ extern void ioport_unmap(void __iomem *);
>  #define ioremap_wc ioremap_nocache
>  #endif
>  
> +#ifndef ARCH_HAS_IOREMAP_WT
> +#define ioremap_wt ioremap_nocache
> +#endif
> +
>  #ifdef CONFIG_PCI
>  /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
>  struct pci_dev;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH v2 4/6] x86, mm: Add set_memory_wt() for WT

[Toshi Kani]

This patch adds set_memory_wt(), set_memory_array_wt(), and
set_pages_array_wt() for setting range(s) of memory to WT.

Note that set_memory_wt() only works for non-RAM ranges at
this point due to the current limitation in reserve_memtype().
This may still be useful when a driver maps the entire NV-DIMM
range with ioremap_cache() and then modifies a specific range
to WT with set_memory_wt().

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 arch/x86/include/asm/cacheflush.h |    6 +++
 arch/x86/mm/pageattr.c            |   73 ++++++++++++++++++++++++++++++++++---
 2 files changed, 72 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
index c912680..5bfd5d0 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -81,7 +81,7 @@ static inline void set_page_memtype(struct page *pg,
 /*
  * The set_memory_* API can be used to change various attributes of a virtual
  * address range. The attributes include:
- * Cachability   : UnCached, WriteCombining, WriteBack
+ * Cachability   : UnCached, WriteCombining, WriteThrough, WriteBack
  * Executability : eXeutable, NoteXecutable
  * Read/Write    : ReadOnly, ReadWrite
  * Presence      : NotPresent
@@ -108,9 +108,11 @@ static inline void set_page_memtype(struct page *pg,
 
 int _set_memory_uc(unsigned long addr, int numpages);
 int _set_memory_wc(unsigned long addr, int numpages);
+int _set_memory_wt(unsigned long addr, int numpages);
 int _set_memory_wb(unsigned long addr, int numpages);
 int set_memory_uc(unsigned long addr, int numpages);
 int set_memory_wc(unsigned long addr, int numpages);
+int set_memory_wt(unsigned long addr, int numpages);
 int set_memory_wb(unsigned long addr, int numpages);
 int set_memory_x(unsigned long addr, int numpages);
 int set_memory_nx(unsigned long addr, int numpages);
@@ -121,10 +123,12 @@ int set_memory_4k(unsigned long addr, int numpages);
 
 int set_memory_array_uc(unsigned long *addr, int addrinarray);
 int set_memory_array_wc(unsigned long *addr, int addrinarray);
+int set_memory_array_wt(unsigned long *addr, int addrinarray);
 int set_memory_array_wb(unsigned long *addr, int addrinarray);
 
 int set_pages_array_uc(struct page **pages, int addrinarray);
 int set_pages_array_wc(struct page **pages, int addrinarray);
+int set_pages_array_wt(struct page **pages, int addrinarray);
 int set_pages_array_wb(struct page **pages, int addrinarray);
 
 /*
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 6917b39..2dda151 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1484,12 +1484,10 @@ EXPORT_SYMBOL(set_memory_uc);
 static int _set_memory_array(unsigned long *addr, int addrinarray,
 		enum page_cache_mode new_type)
 {
+	enum page_cache_mode set_type;
 	int i, j;
 	int ret;
 
-	/*
-	 * for now UC MINUS. see comments in ioremap_nocache()
-	 */
 	for (i = 0; i < addrinarray; i++) {
 		ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE,
 					new_type, NULL);
@@ -1497,9 +1495,12 @@ static int _set_memory_array(unsigned long *addr, int addrinarray,
 			goto out_free;
 	}
 
+	/* If WC, set to UC- first and then WC */
+	set_type = (new_type == _PAGE_CACHE_MODE_WC) ?
+				_PAGE_CACHE_MODE_UC_MINUS : new_type;
+
 	ret = change_page_attr_set(addr, addrinarray,
-				   cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
-				   1);
+				   cachemode2pgprot(set_type), 1);
 
 	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
 		ret = change_page_attr_set_clr(addr, addrinarray,
@@ -1527,10 +1528,22 @@ EXPORT_SYMBOL(set_memory_array_uc);
 
 int set_memory_array_wc(unsigned long *addr, int addrinarray)
 {
+	if (!pat_enabled)
+		return set_memory_array_uc(addr, addrinarray);
+
 	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WC);
 }
 EXPORT_SYMBOL(set_memory_array_wc);
 
+int set_memory_array_wt(unsigned long *addr, int addrinarray)
+{
+	if (!pat_enabled)
+		return set_memory_array_uc(addr, addrinarray);
+
+	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WT);
+}
+EXPORT_SYMBOL(set_memory_array_wt);
+
 int _set_memory_wc(unsigned long addr, int numpages)
 {
 	int ret;
@@ -1574,6 +1587,37 @@ out_err:
 }
 EXPORT_SYMBOL(set_memory_wc);
 
+int _set_memory_wt(unsigned long addr, int numpages)
+{
+	return change_page_attr_set(&addr, numpages,
+				    cachemode2pgprot(_PAGE_CACHE_MODE_WT), 0);
+}
+
+int set_memory_wt(unsigned long addr, int numpages)
+{
+	int ret;
+
+	if (!pat_enabled)
+		return set_memory_uc(addr, numpages);
+
+	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
+			      _PAGE_CACHE_MODE_WT, NULL);
+	if (ret)
+		goto out_err;
+
+	ret = _set_memory_wt(addr, numpages);
+	if (ret)
+		goto out_free;
+
+	return 0;
+
+out_free:
+	free_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE);
+out_err:
+	return ret;
+}
+EXPORT_SYMBOL(set_memory_wt);
+
 int _set_memory_wb(unsigned long addr, int numpages)
 {
 	/* WB cache mode is hard wired to all cache attribute bits being 0 */
@@ -1666,6 +1710,7 @@ static int _set_pages_array(struct page **pages, int addrinarray,
 {
 	unsigned long start;
 	unsigned long end;
+	enum page_cache_mode set_type;
 	int i;
 	int free_idx;
 	int ret;
@@ -1679,8 +1724,12 @@ static int _set_pages_array(struct page **pages, int addrinarray,
 			goto err_out;
 	}
 
+	/* If WC, set to UC- first and then WC */
+	set_type = (new_type == _PAGE_CACHE_MODE_WC) ?
+				_PAGE_CACHE_MODE_UC_MINUS : new_type;
+
 	ret = cpa_set_pages_array(pages, addrinarray,
-			cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS));
+				  cachemode2pgprot(set_type));
 	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
 		ret = change_page_attr_set_clr(NULL, addrinarray,
 					       cachemode2pgprot(
@@ -1710,10 +1759,22 @@ EXPORT_SYMBOL(set_pages_array_uc);
 
 int set_pages_array_wc(struct page **pages, int addrinarray)
 {
+	if (!pat_enabled)
+		return set_pages_array_uc(pages, addrinarray);
+
 	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WC);
 }
 EXPORT_SYMBOL(set_pages_array_wc);
 
+int set_pages_array_wt(struct page **pages, int addrinarray)
+{
+	if (!pat_enabled)
+		return set_pages_array_uc(pages, addrinarray);
+
+	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WT);
+}
+EXPORT_SYMBOL(set_pages_array_wt);
+
 int set_pages_wb(struct page *page, int numpages)
 {
 	unsigned long addr = (unsigned long)page_address(page);

[PATCH v2 4/6] x86, mm: Add set_memory_wt() for WT

[Toshi Kani]

This patch adds set_memory_wt(), set_memory_array_wt(), and
set_pages_array_wt() for setting range(s) of memory to WT.

Note that set_memory_wt() only works for non-RAM ranges at
this point due to the current limitation in reserve_memtype().
This may still be useful when a driver maps the entire NV-DIMM
range with ioremap_cache() and then modifies a specific range
to WT with set_memory_wt().

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 arch/x86/include/asm/cacheflush.h |    6 +++
 arch/x86/mm/pageattr.c            |   73 ++++++++++++++++++++++++++++++++++---
 2 files changed, 72 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
index c912680..5bfd5d0 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -81,7 +81,7 @@ static inline void set_page_memtype(struct page *pg,
 /*
  * The set_memory_* API can be used to change various attributes of a virtual
  * address range. The attributes include:
- * Cachability   : UnCached, WriteCombining, WriteBack
+ * Cachability   : UnCached, WriteCombining, WriteThrough, WriteBack
  * Executability : eXeutable, NoteXecutable
  * Read/Write    : ReadOnly, ReadWrite
  * Presence      : NotPresent
@@ -108,9 +108,11 @@ static inline void set_page_memtype(struct page *pg,
 
 int _set_memory_uc(unsigned long addr, int numpages);
 int _set_memory_wc(unsigned long addr, int numpages);
+int _set_memory_wt(unsigned long addr, int numpages);
 int _set_memory_wb(unsigned long addr, int numpages);
 int set_memory_uc(unsigned long addr, int numpages);
 int set_memory_wc(unsigned long addr, int numpages);
+int set_memory_wt(unsigned long addr, int numpages);
 int set_memory_wb(unsigned long addr, int numpages);
 int set_memory_x(unsigned long addr, int numpages);
 int set_memory_nx(unsigned long addr, int numpages);
@@ -121,10 +123,12 @@ int set_memory_4k(unsigned long addr, int numpages);
 
 int set_memory_array_uc(unsigned long *addr, int addrinarray);
 int set_memory_array_wc(unsigned long *addr, int addrinarray);
+int set_memory_array_wt(unsigned long *addr, int addrinarray);
 int set_memory_array_wb(unsigned long *addr, int addrinarray);
 
 int set_pages_array_uc(struct page **pages, int addrinarray);
 int set_pages_array_wc(struct page **pages, int addrinarray);
+int set_pages_array_wt(struct page **pages, int addrinarray);
 int set_pages_array_wb(struct page **pages, int addrinarray);
 
 /*
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 6917b39..2dda151 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1484,12 +1484,10 @@ EXPORT_SYMBOL(set_memory_uc);
 static int _set_memory_array(unsigned long *addr, int addrinarray,
 		enum page_cache_mode new_type)
 {
+	enum page_cache_mode set_type;
 	int i, j;
 	int ret;
 
-	/*
-	 * for now UC MINUS. see comments in ioremap_nocache()
-	 */
 	for (i = 0; i < addrinarray; i++) {
 		ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE,
 					new_type, NULL);
@@ -1497,9 +1495,12 @@ static int _set_memory_array(unsigned long *addr, int addrinarray,
 			goto out_free;
 	}
 
+	/* If WC, set to UC- first and then WC */
+	set_type = (new_type == _PAGE_CACHE_MODE_WC) ?
+				_PAGE_CACHE_MODE_UC_MINUS : new_type;
+
 	ret = change_page_attr_set(addr, addrinarray,
-				   cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
-				   1);
+				   cachemode2pgprot(set_type), 1);
 
 	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
 		ret = change_page_attr_set_clr(addr, addrinarray,
@@ -1527,10 +1528,22 @@ EXPORT_SYMBOL(set_memory_array_uc);
 
 int set_memory_array_wc(unsigned long *addr, int addrinarray)
 {
+	if (!pat_enabled)
+		return set_memory_array_uc(addr, addrinarray);
+
 	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WC);
 }
 EXPORT_SYMBOL(set_memory_array_wc);
 
+int set_memory_array_wt(unsigned long *addr, int addrinarray)
+{
+	if (!pat_enabled)
+		return set_memory_array_uc(addr, addrinarray);
+
+	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WT);
+}
+EXPORT_SYMBOL(set_memory_array_wt);
+
 int _set_memory_wc(unsigned long addr, int numpages)
 {
 	int ret;
@@ -1574,6 +1587,37 @@ out_err:
 }
 EXPORT_SYMBOL(set_memory_wc);
 
+int _set_memory_wt(unsigned long addr, int numpages)
+{
+	return change_page_attr_set(&addr, numpages,
+				    cachemode2pgprot(_PAGE_CACHE_MODE_WT), 0);
+}
+
+int set_memory_wt(unsigned long addr, int numpages)
+{
+	int ret;
+
+	if (!pat_enabled)
+		return set_memory_uc(addr, numpages);
+
+	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
+			      _PAGE_CACHE_MODE_WT, NULL);
+	if (ret)
+		goto out_err;
+
+	ret = _set_memory_wt(addr, numpages);
+	if (ret)
+		goto out_free;
+
+	return 0;
+
+out_free:
+	free_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE);
+out_err:
+	return ret;
+}
+EXPORT_SYMBOL(set_memory_wt);
+
 int _set_memory_wb(unsigned long addr, int numpages)
 {
 	/* WB cache mode is hard wired to all cache attribute bits being 0 */
@@ -1666,6 +1710,7 @@ static int _set_pages_array(struct page **pages, int addrinarray,
 {
 	unsigned long start;
 	unsigned long end;
+	enum page_cache_mode set_type;
 	int i;
 	int free_idx;
 	int ret;
@@ -1679,8 +1724,12 @@ static int _set_pages_array(struct page **pages, int addrinarray,
 			goto err_out;
 	}
 
+	/* If WC, set to UC- first and then WC */
+	set_type = (new_type == _PAGE_CACHE_MODE_WC) ?
+				_PAGE_CACHE_MODE_UC_MINUS : new_type;
+
 	ret = cpa_set_pages_array(pages, addrinarray,
-			cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS));
+				  cachemode2pgprot(set_type));
 	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
 		ret = change_page_attr_set_clr(NULL, addrinarray,
 					       cachemode2pgprot(
@@ -1710,10 +1759,22 @@ EXPORT_SYMBOL(set_pages_array_uc);
 
 int set_pages_array_wc(struct page **pages, int addrinarray)
 {
+	if (!pat_enabled)
+		return set_pages_array_uc(pages, addrinarray);
+
 	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WC);
 }
 EXPORT_SYMBOL(set_pages_array_wc);
 
+int set_pages_array_wt(struct page **pages, int addrinarray)
+{
+	if (!pat_enabled)
+		return set_pages_array_uc(pages, addrinarray);
+
+	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WT);
+}
+EXPORT_SYMBOL(set_pages_array_wt);
+
 int set_pages_wb(struct page *page, int numpages)
 {
 	unsigned long addr = (unsigned long)page_address(page);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 4/6] x86, mm: Add set_memory_wt() for WT

[Konrad Rzeszutek Wilk]

On Wed, Sep 10, 2014 at 10:51:48AM -0600, Toshi Kani wrote:
> This patch adds set_memory_wt(), set_memory_array_wt(), and
> set_pages_array_wt() for setting range(s) of memory to WT.
> 
> Note that set_memory_wt() only works for non-RAM ranges at
> this point due to the current limitation in reserve_memtype().
> This may still be useful when a driver maps the entire NV-DIMM
> range with ioremap_cache() and then modifies a specific range
> to WT with set_memory_wt().
> 
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/include/asm/cacheflush.h |    6 +++
>  arch/x86/mm/pageattr.c            |   73 ++++++++++++++++++++++++++++++++++---
>  2 files changed, 72 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
> index c912680..5bfd5d0 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -81,7 +81,7 @@ static inline void set_page_memtype(struct page *pg,
>  /*
>   * The set_memory_* API can be used to change various attributes of a virtual
>   * address range. The attributes include:
> - * Cachability   : UnCached, WriteCombining, WriteBack
> + * Cachability   : UnCached, WriteCombining, WriteThrough, WriteBack
>   * Executability : eXeutable, NoteXecutable
>   * Read/Write    : ReadOnly, ReadWrite
>   * Presence      : NotPresent
> @@ -108,9 +108,11 @@ static inline void set_page_memtype(struct page *pg,
>  
>  int _set_memory_uc(unsigned long addr, int numpages);
>  int _set_memory_wc(unsigned long addr, int numpages);
> +int _set_memory_wt(unsigned long addr, int numpages);
>  int _set_memory_wb(unsigned long addr, int numpages);
>  int set_memory_uc(unsigned long addr, int numpages);
>  int set_memory_wc(unsigned long addr, int numpages);
> +int set_memory_wt(unsigned long addr, int numpages);
>  int set_memory_wb(unsigned long addr, int numpages);
>  int set_memory_x(unsigned long addr, int numpages);
>  int set_memory_nx(unsigned long addr, int numpages);
> @@ -121,10 +123,12 @@ int set_memory_4k(unsigned long addr, int numpages);
>  
>  int set_memory_array_uc(unsigned long *addr, int addrinarray);
>  int set_memory_array_wc(unsigned long *addr, int addrinarray);
> +int set_memory_array_wt(unsigned long *addr, int addrinarray);
>  int set_memory_array_wb(unsigned long *addr, int addrinarray);
>  
>  int set_pages_array_uc(struct page **pages, int addrinarray);
>  int set_pages_array_wc(struct page **pages, int addrinarray);
> +int set_pages_array_wt(struct page **pages, int addrinarray);
>  int set_pages_array_wb(struct page **pages, int addrinarray);
>  
>  /*
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 6917b39..2dda151 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -1484,12 +1484,10 @@ EXPORT_SYMBOL(set_memory_uc);
>  static int _set_memory_array(unsigned long *addr, int addrinarray,
>  		enum page_cache_mode new_type)
>  {
> +	enum page_cache_mode set_type;
>  	int i, j;
>  	int ret;
>  
> -	/*
> -	 * for now UC MINUS. see comments in ioremap_nocache()
> -	 */
>  	for (i = 0; i < addrinarray; i++) {
>  		ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE,
>  					new_type, NULL);
> @@ -1497,9 +1495,12 @@ static int _set_memory_array(unsigned long *addr, int addrinarray,
>  			goto out_free;
>  	}
>  
> +	/* If WC, set to UC- first and then WC */
> +	set_type = (new_type == _PAGE_CACHE_MODE_WC) ?
> +				_PAGE_CACHE_MODE_UC_MINUS : new_type;
> +
>  	ret = change_page_attr_set(addr, addrinarray,
> -				   cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
> -				   1);
> +				   cachemode2pgprot(set_type), 1);
>  
>  	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
>  		ret = change_page_attr_set_clr(addr, addrinarray,
> @@ -1527,10 +1528,22 @@ EXPORT_SYMBOL(set_memory_array_uc);
>  
>  int set_memory_array_wc(unsigned long *addr, int addrinarray)
>  {
> +	if (!pat_enabled)
> +		return set_memory_array_uc(addr, addrinarray);
> +
>  	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WC);
>  }
>  EXPORT_SYMBOL(set_memory_array_wc);
>  
> +int set_memory_array_wt(unsigned long *addr, int addrinarray)
> +{
> +	if (!pat_enabled)
> +		return set_memory_array_uc(addr, addrinarray);
> +
> +	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WT);
> +}
> +EXPORT_SYMBOL(set_memory_array_wt);
> +
>  int _set_memory_wc(unsigned long addr, int numpages)
>  {
>  	int ret;
> @@ -1574,6 +1587,37 @@ out_err:
>  }
>  EXPORT_SYMBOL(set_memory_wc);
>  
> +int _set_memory_wt(unsigned long addr, int numpages)
> +{
> +	return change_page_attr_set(&addr, numpages,
> +				    cachemode2pgprot(_PAGE_CACHE_MODE_WT), 0);
> +}
> +
> +int set_memory_wt(unsigned long addr, int numpages)
> +{
> +	int ret;
> +
> +	if (!pat_enabled)
> +		return set_memory_uc(addr, numpages);
> +
> +	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
> +			      _PAGE_CACHE_MODE_WT, NULL);
> +	if (ret)
> +		goto out_err;
> +
> +	ret = _set_memory_wt(addr, numpages);
> +	if (ret)
> +		goto out_free;
> +
> +	return 0;
> +
> +out_free:
> +	free_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE);
> +out_err:
> +	return ret;
> +}
> +EXPORT_SYMBOL(set_memory_wt);
> +
>  int _set_memory_wb(unsigned long addr, int numpages)
>  {
>  	/* WB cache mode is hard wired to all cache attribute bits being 0 */
> @@ -1666,6 +1710,7 @@ static int _set_pages_array(struct page **pages, int addrinarray,
>  {
>  	unsigned long start;
>  	unsigned long end;
> +	enum page_cache_mode set_type;
>  	int i;
>  	int free_idx;
>  	int ret;
> @@ -1679,8 +1724,12 @@ static int _set_pages_array(struct page **pages, int addrinarray,
>  			goto err_out;
>  	}
>  
> +	/* If WC, set to UC- first and then WC */
> +	set_type = (new_type == _PAGE_CACHE_MODE_WC) ?
> +				_PAGE_CACHE_MODE_UC_MINUS : new_type;
> +
>  	ret = cpa_set_pages_array(pages, addrinarray,
> -			cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS));
> +				  cachemode2pgprot(set_type));
>  	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
>  		ret = change_page_attr_set_clr(NULL, addrinarray,
>  					       cachemode2pgprot(
> @@ -1710,10 +1759,22 @@ EXPORT_SYMBOL(set_pages_array_uc);
>  
>  int set_pages_array_wc(struct page **pages, int addrinarray)
>  {
> +	if (!pat_enabled)
> +		return set_pages_array_uc(pages, addrinarray);
> +
>  	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WC);
>  }
>  EXPORT_SYMBOL(set_pages_array_wc);
>  
> +int set_pages_array_wt(struct page **pages, int addrinarray)
> +{
> +	if (!pat_enabled)
> +		return set_pages_array_uc(pages, addrinarray);
> +
> +	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WT);
> +}
> +EXPORT_SYMBOL(set_pages_array_wt);
> +
>  int set_pages_wb(struct page *page, int numpages)
>  {
>  	unsigned long addr = (unsigned long)page_address(page);

Re: [PATCH v2 4/6] x86, mm: Add set_memory_wt() for WT

[Konrad Rzeszutek Wilk]

On Wed, Sep 10, 2014 at 10:51:48AM -0600, Toshi Kani wrote:
> This patch adds set_memory_wt(), set_memory_array_wt(), and
> set_pages_array_wt() for setting range(s) of memory to WT.
> 
> Note that set_memory_wt() only works for non-RAM ranges at
> this point due to the current limitation in reserve_memtype().
> This may still be useful when a driver maps the entire NV-DIMM
> range with ioremap_cache() and then modifies a specific range
> to WT with set_memory_wt().
> 
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/include/asm/cacheflush.h |    6 +++
>  arch/x86/mm/pageattr.c            |   73 ++++++++++++++++++++++++++++++++++---
>  2 files changed, 72 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
> index c912680..5bfd5d0 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -81,7 +81,7 @@ static inline void set_page_memtype(struct page *pg,
>  /*
>   * The set_memory_* API can be used to change various attributes of a virtual
>   * address range. The attributes include:
> - * Cachability   : UnCached, WriteCombining, WriteBack
> + * Cachability   : UnCached, WriteCombining, WriteThrough, WriteBack
>   * Executability : eXeutable, NoteXecutable
>   * Read/Write    : ReadOnly, ReadWrite
>   * Presence      : NotPresent
> @@ -108,9 +108,11 @@ static inline void set_page_memtype(struct page *pg,
>  
>  int _set_memory_uc(unsigned long addr, int numpages);
>  int _set_memory_wc(unsigned long addr, int numpages);
> +int _set_memory_wt(unsigned long addr, int numpages);
>  int _set_memory_wb(unsigned long addr, int numpages);
>  int set_memory_uc(unsigned long addr, int numpages);
>  int set_memory_wc(unsigned long addr, int numpages);
> +int set_memory_wt(unsigned long addr, int numpages);
>  int set_memory_wb(unsigned long addr, int numpages);
>  int set_memory_x(unsigned long addr, int numpages);
>  int set_memory_nx(unsigned long addr, int numpages);
> @@ -121,10 +123,12 @@ int set_memory_4k(unsigned long addr, int numpages);
>  
>  int set_memory_array_uc(unsigned long *addr, int addrinarray);
>  int set_memory_array_wc(unsigned long *addr, int addrinarray);
> +int set_memory_array_wt(unsigned long *addr, int addrinarray);
>  int set_memory_array_wb(unsigned long *addr, int addrinarray);
>  
>  int set_pages_array_uc(struct page **pages, int addrinarray);
>  int set_pages_array_wc(struct page **pages, int addrinarray);
> +int set_pages_array_wt(struct page **pages, int addrinarray);
>  int set_pages_array_wb(struct page **pages, int addrinarray);
>  
>  /*
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 6917b39..2dda151 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -1484,12 +1484,10 @@ EXPORT_SYMBOL(set_memory_uc);
>  static int _set_memory_array(unsigned long *addr, int addrinarray,
>  		enum page_cache_mode new_type)
>  {
> +	enum page_cache_mode set_type;
>  	int i, j;
>  	int ret;
>  
> -	/*
> -	 * for now UC MINUS. see comments in ioremap_nocache()
> -	 */
>  	for (i = 0; i < addrinarray; i++) {
>  		ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE,
>  					new_type, NULL);
> @@ -1497,9 +1495,12 @@ static int _set_memory_array(unsigned long *addr, int addrinarray,
>  			goto out_free;
>  	}
>  
> +	/* If WC, set to UC- first and then WC */
> +	set_type = (new_type == _PAGE_CACHE_MODE_WC) ?
> +				_PAGE_CACHE_MODE_UC_MINUS : new_type;
> +
>  	ret = change_page_attr_set(addr, addrinarray,
> -				   cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
> -				   1);
> +				   cachemode2pgprot(set_type), 1);
>  
>  	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
>  		ret = change_page_attr_set_clr(addr, addrinarray,
> @@ -1527,10 +1528,22 @@ EXPORT_SYMBOL(set_memory_array_uc);
>  
>  int set_memory_array_wc(unsigned long *addr, int addrinarray)
>  {
> +	if (!pat_enabled)
> +		return set_memory_array_uc(addr, addrinarray);
> +
>  	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WC);
>  }
>  EXPORT_SYMBOL(set_memory_array_wc);
>  
> +int set_memory_array_wt(unsigned long *addr, int addrinarray)
> +{
> +	if (!pat_enabled)
> +		return set_memory_array_uc(addr, addrinarray);
> +
> +	return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WT);
> +}
> +EXPORT_SYMBOL(set_memory_array_wt);
> +
>  int _set_memory_wc(unsigned long addr, int numpages)
>  {
>  	int ret;
> @@ -1574,6 +1587,37 @@ out_err:
>  }
>  EXPORT_SYMBOL(set_memory_wc);
>  
> +int _set_memory_wt(unsigned long addr, int numpages)
> +{
> +	return change_page_attr_set(&addr, numpages,
> +				    cachemode2pgprot(_PAGE_CACHE_MODE_WT), 0);
> +}
> +
> +int set_memory_wt(unsigned long addr, int numpages)
> +{
> +	int ret;
> +
> +	if (!pat_enabled)
> +		return set_memory_uc(addr, numpages);
> +
> +	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
> +			      _PAGE_CACHE_MODE_WT, NULL);
> +	if (ret)
> +		goto out_err;
> +
> +	ret = _set_memory_wt(addr, numpages);
> +	if (ret)
> +		goto out_free;
> +
> +	return 0;
> +
> +out_free:
> +	free_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE);
> +out_err:
> +	return ret;
> +}
> +EXPORT_SYMBOL(set_memory_wt);
> +
>  int _set_memory_wb(unsigned long addr, int numpages)
>  {
>  	/* WB cache mode is hard wired to all cache attribute bits being 0 */
> @@ -1666,6 +1710,7 @@ static int _set_pages_array(struct page **pages, int addrinarray,
>  {
>  	unsigned long start;
>  	unsigned long end;
> +	enum page_cache_mode set_type;
>  	int i;
>  	int free_idx;
>  	int ret;
> @@ -1679,8 +1724,12 @@ static int _set_pages_array(struct page **pages, int addrinarray,
>  			goto err_out;
>  	}
>  
> +	/* If WC, set to UC- first and then WC */
> +	set_type = (new_type == _PAGE_CACHE_MODE_WC) ?
> +				_PAGE_CACHE_MODE_UC_MINUS : new_type;
> +
>  	ret = cpa_set_pages_array(pages, addrinarray,
> -			cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS));
> +				  cachemode2pgprot(set_type));
>  	if (!ret && new_type == _PAGE_CACHE_MODE_WC)
>  		ret = change_page_attr_set_clr(NULL, addrinarray,
>  					       cachemode2pgprot(
> @@ -1710,10 +1759,22 @@ EXPORT_SYMBOL(set_pages_array_uc);
>  
>  int set_pages_array_wc(struct page **pages, int addrinarray)
>  {
> +	if (!pat_enabled)
> +		return set_pages_array_uc(pages, addrinarray);
> +
>  	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WC);
>  }
>  EXPORT_SYMBOL(set_pages_array_wc);
>  
> +int set_pages_array_wt(struct page **pages, int addrinarray)
> +{
> +	if (!pat_enabled)
> +		return set_pages_array_uc(pages, addrinarray);
> +
> +	return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WT);
> +}
> +EXPORT_SYMBOL(set_pages_array_wt);
> +
>  int set_pages_wb(struct page *page, int numpages)
>  {
>  	unsigned long addr = (unsigned long)page_address(page);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH v2 5/6] x86, mm, pat: Add pgprot_writethrough() for WT

[Toshi Kani]

This patch adds pgprot_writethrough() for setting WT to a given
pgprot_t.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 arch/x86/include/asm/pgtable_types.h |    3 +++
 arch/x86/mm/pat.c                    |   10 ++++++++++
 include/asm-generic/pgtable.h        |    4 ++++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index bd2f50f..cc7c65d 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -394,6 +394,9 @@ extern int nx_enabled;
 #define pgprot_writecombine	pgprot_writecombine
 extern pgprot_t pgprot_writecombine(pgprot_t prot);
 
+#define pgprot_writethrough	pgprot_writethrough
+extern pgprot_t pgprot_writethrough(pgprot_t prot);
+
 /* Indicate that x86 has its own track and untrack pfn vma functions */
 #define __HAVE_PFNMAP_TRACKING
 
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 7644967..97aab95 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -875,6 +875,16 @@ pgprot_t pgprot_writecombine(pgprot_t prot)
 }
 EXPORT_SYMBOL_GPL(pgprot_writecombine);
 
+pgprot_t pgprot_writethrough(pgprot_t prot)
+{
+	if (pat_enabled)
+		return __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_WT));
+	else
+		return pgprot_noncached(prot);
+}
+EXPORT_SYMBOL_GPL(pgprot_writethrough);
+
 #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT)
 
 static struct memtype *memtype_get_idx(loff_t pos)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 53b2acc..1af0ed9 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
 #define pgprot_writecombine pgprot_noncached
 #endif
 
+#ifndef pgprot_writethrough
+#define pgprot_writethrough pgprot_noncached
+#endif
+
 /*
  * When walking page tables, get the address of the next boundary,
  * or the end address of the range if that comes earlier.  Although no

[PATCH v2 5/6] x86, mm, pat: Add pgprot_writethrough() for WT

[Toshi Kani]

This patch adds pgprot_writethrough() for setting WT to a given
pgprot_t.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 arch/x86/include/asm/pgtable_types.h |    3 +++
 arch/x86/mm/pat.c                    |   10 ++++++++++
 include/asm-generic/pgtable.h        |    4 ++++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index bd2f50f..cc7c65d 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -394,6 +394,9 @@ extern int nx_enabled;
 #define pgprot_writecombine	pgprot_writecombine
 extern pgprot_t pgprot_writecombine(pgprot_t prot);
 
+#define pgprot_writethrough	pgprot_writethrough
+extern pgprot_t pgprot_writethrough(pgprot_t prot);
+
 /* Indicate that x86 has its own track and untrack pfn vma functions */
 #define __HAVE_PFNMAP_TRACKING
 
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 7644967..97aab95 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -875,6 +875,16 @@ pgprot_t pgprot_writecombine(pgprot_t prot)
 }
 EXPORT_SYMBOL_GPL(pgprot_writecombine);
 
+pgprot_t pgprot_writethrough(pgprot_t prot)
+{
+	if (pat_enabled)
+		return __pgprot(pgprot_val(prot) |
+				cachemode2protval(_PAGE_CACHE_MODE_WT));
+	else
+		return pgprot_noncached(prot);
+}
+EXPORT_SYMBOL_GPL(pgprot_writethrough);
+
 #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT)
 
 static struct memtype *memtype_get_idx(loff_t pos)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 53b2acc..1af0ed9 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
 #define pgprot_writecombine pgprot_noncached
 #endif
 
+#ifndef pgprot_writethrough
+#define pgprot_writethrough pgprot_noncached
+#endif
+
 /*
  * When walking page tables, get the address of the next boundary,
  * or the end address of the range if that comes earlier.  Although no

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 5/6] x86, mm, pat: Add pgprot_writethrough() for WT

[Konrad Rzeszutek Wilk]

On Wed, Sep 10, 2014 at 10:51:49AM -0600, Toshi Kani wrote:
> This patch adds pgprot_writethrough() for setting WT to a given
> pgprot_t.
> 
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/include/asm/pgtable_types.h |    3 +++
>  arch/x86/mm/pat.c                    |   10 ++++++++++
>  include/asm-generic/pgtable.h        |    4 ++++
>  3 files changed, 17 insertions(+)
> 
> diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
> index bd2f50f..cc7c65d 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -394,6 +394,9 @@ extern int nx_enabled;
>  #define pgprot_writecombine	pgprot_writecombine
>  extern pgprot_t pgprot_writecombine(pgprot_t prot);
>  
> +#define pgprot_writethrough	pgprot_writethrough
> +extern pgprot_t pgprot_writethrough(pgprot_t prot);
> +
>  /* Indicate that x86 has its own track and untrack pfn vma functions */
>  #define __HAVE_PFNMAP_TRACKING
>  
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 7644967..97aab95 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -875,6 +875,16 @@ pgprot_t pgprot_writecombine(pgprot_t prot)
>  }
>  EXPORT_SYMBOL_GPL(pgprot_writecombine);
>  
> +pgprot_t pgprot_writethrough(pgprot_t prot)
> +{
> +	if (pat_enabled)
> +		return __pgprot(pgprot_val(prot) |
> +				cachemode2protval(_PAGE_CACHE_MODE_WT));
> +	else
> +		return pgprot_noncached(prot);
> +}
> +EXPORT_SYMBOL_GPL(pgprot_writethrough);
> +
>  #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT)
>  
>  static struct memtype *memtype_get_idx(loff_t pos)
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 53b2acc..1af0ed9 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
>  #define pgprot_writecombine pgprot_noncached
>  #endif
>  
> +#ifndef pgprot_writethrough
> +#define pgprot_writethrough pgprot_noncached
> +#endif
> +
>  /*
>   * When walking page tables, get the address of the next boundary,
>   * or the end address of the range if that comes earlier.  Although no

Re: [PATCH v2 5/6] x86, mm, pat: Add pgprot_writethrough() for WT

[Konrad Rzeszutek Wilk]

On Wed, Sep 10, 2014 at 10:51:49AM -0600, Toshi Kani wrote:
> This patch adds pgprot_writethrough() for setting WT to a given
> pgprot_t.
> 
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/include/asm/pgtable_types.h |    3 +++
>  arch/x86/mm/pat.c                    |   10 ++++++++++
>  include/asm-generic/pgtable.h        |    4 ++++
>  3 files changed, 17 insertions(+)
> 
> diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
> index bd2f50f..cc7c65d 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -394,6 +394,9 @@ extern int nx_enabled;
>  #define pgprot_writecombine	pgprot_writecombine
>  extern pgprot_t pgprot_writecombine(pgprot_t prot);
>  
> +#define pgprot_writethrough	pgprot_writethrough
> +extern pgprot_t pgprot_writethrough(pgprot_t prot);
> +
>  /* Indicate that x86 has its own track and untrack pfn vma functions */
>  #define __HAVE_PFNMAP_TRACKING
>  
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 7644967..97aab95 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -875,6 +875,16 @@ pgprot_t pgprot_writecombine(pgprot_t prot)
>  }
>  EXPORT_SYMBOL_GPL(pgprot_writecombine);
>  
> +pgprot_t pgprot_writethrough(pgprot_t prot)
> +{
> +	if (pat_enabled)
> +		return __pgprot(pgprot_val(prot) |
> +				cachemode2protval(_PAGE_CACHE_MODE_WT));
> +	else
> +		return pgprot_noncached(prot);
> +}
> +EXPORT_SYMBOL_GPL(pgprot_writethrough);
> +
>  #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT)
>  
>  static struct memtype *memtype_get_idx(loff_t pos)
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 53b2acc..1af0ed9 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
>  #define pgprot_writecombine pgprot_noncached
>  #endif
>  
> +#ifndef pgprot_writethrough
> +#define pgprot_writethrough pgprot_noncached
> +#endif
> +
>  /*
>   * When walking page tables, get the address of the next boundary,
>   * or the end address of the range if that comes earlier.  Although no

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

This patch updates the PAT documentation file to cover the new
WT mapping interfaces.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 Documentation/x86/pat.txt |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index cf08c9f..445caab 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -12,7 +12,7 @@ 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 and Uncached Minus.
+Write-combined, Write-through and Uncached Minus.
 
 
 PAT APIs
@@ -38,12 +38,17 @@ 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          |    *1    |    --      |       WT         |
+ set_memory_wb         |          |            |                  |
+                       |          |            |                  |
 pci sysfs resource     |    --    |    --      |       UC-        |
                        |          |            |                  |
 pci sysfs resource_wc  |    --    |    --      |       WC         |
@@ -79,6 +84,7 @@ pci proc               |    --    |    --      |       WC         |
  MTRR says !WB         |          |            |                  |
                        |          |            |                  |
 -------------------------------------------------------------------
+*1: -EINVAL due to the current limitation in reserve_memtype().
 
 Advanced APIs for drivers
 -------------------------
@@ -115,8 +121,8 @@ 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] and set_memory_wb should be used in pairs, where driver will
-first make a region uc or wc and switch it back to wb after use.
+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.
@@ -126,6 +132,8 @@ types.
 
 Drivers should use set_memory_[uc|wc] to set access type for RAM ranges.
 
+Drivers may map the entire NV-DIMM range with ioremap_cache and then change
+a specific range to wt with set_memory_wt.
 
 PAT debugging
 -------------

[PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

This patch updates the PAT documentation file to cover the new
WT mapping interfaces.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
 Documentation/x86/pat.txt |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index cf08c9f..445caab 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -12,7 +12,7 @@ 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 and Uncached Minus.
+Write-combined, Write-through and Uncached Minus.
 
 
 PAT APIs
@@ -38,12 +38,17 @@ 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          |    *1    |    --      |       WT         |
+ set_memory_wb         |          |            |                  |
+                       |          |            |                  |
 pci sysfs resource     |    --    |    --      |       UC-        |
                        |          |            |                  |
 pci sysfs resource_wc  |    --    |    --      |       WC         |
@@ -79,6 +84,7 @@ pci proc               |    --    |    --      |       WC         |
  MTRR says !WB         |          |            |                  |
                        |          |            |                  |
 -------------------------------------------------------------------
+*1: -EINVAL due to the current limitation in reserve_memtype().
 
 Advanced APIs for drivers
 -------------------------
@@ -115,8 +121,8 @@ 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] and set_memory_wb should be used in pairs, where driver will
-first make a region uc or wc and switch it back to wb after use.
+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.
@@ -126,6 +132,8 @@ types.
 
 Drivers should use set_memory_[uc|wc] to set access type for RAM ranges.
 
+Drivers may map the entire NV-DIMM range with ioremap_cache and then change
+a specific range to wt with set_memory_wt.
 
 PAT debugging
 -------------

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> +a specific range to wt with set_memory_wt.

That's mighty specific :)

It's also not all that informative.  Are you supposed to set the
memory back before iounmapping?  Can you do this with set_memory_wc on
an uncached mapping?

--Andy

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> +a specific range to wt with set_memory_wt.

That's mighty specific :)

It's also not all that informative.  Are you supposed to set the
memory back before iounmapping?  Can you do this with set_memory_wc on
an uncached mapping?

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> > +a specific range to wt with set_memory_wt.
> 
> That's mighty specific :)

How about below?

Drivers may use set_memory_wt to set WT type for cached reserve ranges.

> It's also not all that informative.  Are you supposed to set the
> memory back before iounmapping?  

Setting back to WB before iounmap is not required, but set_memory_wb is
used when it wants to put it back to WB before unmapping.

> Can you do this with set_memory_wc on
> an uncached mapping?

The table lists interfaces and their intended usage.  Using
set_memory_wc on an uncached mapping probably works, but is not an
intended use.

Thanks,
-Toshi

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> > +a specific range to wt with set_memory_wt.
> 
> That's mighty specific :)

How about below?

Drivers may use set_memory_wt to set WT type for cached reserve ranges.

> It's also not all that informative.  Are you supposed to set the
> memory back before iounmapping?  

Setting back to WB before iounmap is not required, but set_memory_wb is
used when it wants to put it back to WB before unmapping.

> Can you do this with set_memory_wc on
> an uncached mapping?

The table lists interfaces and their intended usage.  Using
set_memory_wc on an uncached mapping probably works, but is not an
intended use.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
>> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
>> > +a specific range to wt with set_memory_wt.
>>
>> That's mighty specific :)
>
> How about below?
>
> Drivers may use set_memory_wt to set WT type for cached reserve ranges.

Do they have to be cached?

How about:

Drivers may call set_memory_wt on ioremapped ranges.  In this case,
there is no need to change the memory type back before calling
iounmap.

(Or only on cached ioremapped ranges if that is, in fact, the case.)

--Andy

>
>> It's also not all that informative.  Are you supposed to set the
>> memory back before iounmapping?
>
> Setting back to WB before iounmap is not required, but set_memory_wb is
> used when it wants to put it back to WB before unmapping.
>
>> Can you do this with set_memory_wc on
>> an uncached mapping?
>
> The table lists interfaces and their intended usage.  Using
> set_memory_wc on an uncached mapping probably works, but is not an
> intended use.
>
> Thanks,
> -Toshi
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Andy Lutomirski]

On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
>> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
>> > +a specific range to wt with set_memory_wt.
>>
>> That's mighty specific :)
>
> How about below?
>
> Drivers may use set_memory_wt to set WT type for cached reserve ranges.

Do they have to be cached?

How about:

Drivers may call set_memory_wt on ioremapped ranges.  In this case,
there is no need to change the memory type back before calling
iounmap.

(Or only on cached ioremapped ranges if that is, in fact, the case.)

--Andy

>
>> It's also not all that informative.  Are you supposed to set the
>> memory back before iounmapping?
>
> Setting back to WB before iounmap is not required, but set_memory_wb is
> used when it wants to put it back to WB before unmapping.
>
>> Can you do this with set_memory_wc on
>> an uncached mapping?
>
> The table lists interfaces and their intended usage.  Using
> set_memory_wc on an uncached mapping probably works, but is not an
> intended use.
>
> Thanks,
> -Toshi
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> >> > +a specific range to wt with set_memory_wt.
> >>
> >> That's mighty specific :)
> >
> > How about below?
> >
> > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
> 
> Do they have to be cached?

Yes, set_memory_xyz only supports WB->type->WB transition.

> How about:
> 
> Drivers may call set_memory_wt on ioremapped ranges.  In this case,
> there is no need to change the memory type back before calling
> iounmap.
> 
> (Or only on cached ioremapped ranges if that is, in fact, the case.)

Sounds good.  Yes, I will use cashed ioremapped ranges.

Thanks,
-Toshi

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> >> > +a specific range to wt with set_memory_wt.
> >>
> >> That's mighty specific :)
> >
> > How about below?
> >
> > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
> 
> Do they have to be cached?

Yes, set_memory_xyz only supports WB->type->WB transition.

> How about:
> 
> Drivers may call set_memory_wt on ioremapped ranges.  In this case,
> there is no need to change the memory type back before calling
> iounmap.
> 
> (Or only on cached ioremapped ranges if that is, in fact, the case.)

Sounds good.  Yes, I will use cashed ioremapped ranges.

Thanks,
-Toshi


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> > >> > +a specific range to wt with set_memory_wt.
> > >>
> > >> That's mighty specific :)
> > >
> > > How about below?
> > >
> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
> > 
> > Do they have to be cached?
> 
> Yes, set_memory_xyz only supports WB->type->WB transition.
> 
> > How about:
> > 
> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
> > there is no need to change the memory type back before calling
> > iounmap.
> > 
> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
> 
> Sounds good.  Yes, I will use cashed ioremapped ranges.

Well, testing "no need to change the memory type back before calling
iounmap" turns out to be a good test case.  I realized that
set_memory_xyz only works properly for RAM.  There are two problems for
using this interface for ioremapped ranges.

1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
__pa() translates the addr into a fake physical address when it is an
ioremapped address.

2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
state is managed untracked.  Hence, WB->new->WB is not considered as a
conflict.  For ioremapped ranges, WB is tracked in the same way as other
cache types.  Hence, WB->new is considered as a conflict.

In my previous testing, 2) was undetected since 1) led using a fake
physical address which was not tracked for WB.  This made ioremapped
ranges worked just like RAM. :-( 

Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
set_memory_xyz is already slow, but this makes it even slower, though.

For 2), WB has to be continuously tracked in order to detect aliasing,
ex. ioremap_cache and ioremap to a same address.  So, I think
reserve_memtype() needs the following changes:
 - Add a new arg to see if an operation is to create a new mapping or to
change cache attribute.
 - Track overlapping maps so that cache type change to an overlapping
range can be detected and failed.

This level of changes requires a separate set of patches if we pursue to
support ioremapped ranges.  So, I am considering to take one of the two
options below.

A) Drop the patch for set_memory_wt.

B) Keep the patch for set_memory_wt, but document that it fails with
-EINVAL and its use is for RAM only.

Any suggestion?
Thanks,
-Toshi

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> > >> > +a specific range to wt with set_memory_wt.
> > >>
> > >> That's mighty specific :)
> > >
> > > How about below?
> > >
> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
> > 
> > Do they have to be cached?
> 
> Yes, set_memory_xyz only supports WB->type->WB transition.
> 
> > How about:
> > 
> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
> > there is no need to change the memory type back before calling
> > iounmap.
> > 
> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
> 
> Sounds good.  Yes, I will use cashed ioremapped ranges.

Well, testing "no need to change the memory type back before calling
iounmap" turns out to be a good test case.  I realized that
set_memory_xyz only works properly for RAM.  There are two problems for
using this interface for ioremapped ranges.

1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
__pa() translates the addr into a fake physical address when it is an
ioremapped address.

2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
state is managed untracked.  Hence, WB->new->WB is not considered as a
conflict.  For ioremapped ranges, WB is tracked in the same way as other
cache types.  Hence, WB->new is considered as a conflict.

In my previous testing, 2) was undetected since 1) led using a fake
physical address which was not tracked for WB.  This made ioremapped
ranges worked just like RAM. :-( 

Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
set_memory_xyz is already slow, but this makes it even slower, though.

For 2), WB has to be continuously tracked in order to detect aliasing,
ex. ioremap_cache and ioremap to a same address.  So, I think
reserve_memtype() needs the following changes:
 - Add a new arg to see if an operation is to create a new mapping or to
change cache attribute.
 - Track overlapping maps so that cache type change to an overlapping
range can be detected and failed.

This level of changes requires a separate set of patches if we pursue to
support ioremapped ranges.  So, I am considering to take one of the two
options below.

A) Drop the patch for set_memory_wt.

B) Keep the patch for set_memory_wt, but document that it fails with
-EINVAL and its use is for RAM only.

Any suggestion?
Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Andy Lutomirski]

On Mon, Sep 15, 2014 at 2:19 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
>> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
>> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
>> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
>> > >> > +a specific range to wt with set_memory_wt.
>> > >>
>> > >> That's mighty specific :)
>> > >
>> > > How about below?
>> > >
>> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
>> >
>> > Do they have to be cached?
>>
>> Yes, set_memory_xyz only supports WB->type->WB transition.
>>
>> > How about:
>> >
>> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
>> > there is no need to change the memory type back before calling
>> > iounmap.
>> >
>> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
>>
>> Sounds good.  Yes, I will use cashed ioremapped ranges.
>
> Well, testing "no need to change the memory type back before calling
> iounmap" turns out to be a good test case.  I realized that
> set_memory_xyz only works properly for RAM.  There are two problems for
> using this interface for ioremapped ranges.
>
> 1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
> __pa() translates the addr into a fake physical address when it is an
> ioremapped address.
>
> 2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
> state is managed untracked.  Hence, WB->new->WB is not considered as a
> conflict.  For ioremapped ranges, WB is tracked in the same way as other
> cache types.  Hence, WB->new is considered as a conflict.
>
> In my previous testing, 2) was undetected since 1) led using a fake
> physical address which was not tracked for WB.  This made ioremapped
> ranges worked just like RAM. :-(
>
> Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
> set_memory_xyz is already slow, but this makes it even slower, though.
>
> For 2), WB has to be continuously tracked in order to detect aliasing,
> ex. ioremap_cache and ioremap to a same address.  So, I think
> reserve_memtype() needs the following changes:
>  - Add a new arg to see if an operation is to create a new mapping or to
> change cache attribute.
>  - Track overlapping maps so that cache type change to an overlapping
> range can be detected and failed.
>
> This level of changes requires a separate set of patches if we pursue to
> support ioremapped ranges.  So, I am considering to take one of the two
> options below.
>
> A) Drop the patch for set_memory_wt.
>
> B) Keep the patch for set_memory_wt, but document that it fails with
> -EINVAL and its use is for RAM only.
>

I vote A.  I see no great reason to add code that can't be used.  Once
someone needs this ability, they can add it :)

It's too bad that ioremap is called ioremap and not iomap.  Otherwise
the natural solution would be to add a different function call
ioremap_wt that's like set_memory_wt but for ioremap ranges.  Calling
it ioreremap_wt sounds kind of disgusting :)

--Andy

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Andy Lutomirski]

On Mon, Sep 15, 2014 at 2:19 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
>> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
>> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
>> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
>> > >> > +a specific range to wt with set_memory_wt.
>> > >>
>> > >> That's mighty specific :)
>> > >
>> > > How about below?
>> > >
>> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
>> >
>> > Do they have to be cached?
>>
>> Yes, set_memory_xyz only supports WB->type->WB transition.
>>
>> > How about:
>> >
>> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
>> > there is no need to change the memory type back before calling
>> > iounmap.
>> >
>> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
>>
>> Sounds good.  Yes, I will use cashed ioremapped ranges.
>
> Well, testing "no need to change the memory type back before calling
> iounmap" turns out to be a good test case.  I realized that
> set_memory_xyz only works properly for RAM.  There are two problems for
> using this interface for ioremapped ranges.
>
> 1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
> __pa() translates the addr into a fake physical address when it is an
> ioremapped address.
>
> 2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
> state is managed untracked.  Hence, WB->new->WB is not considered as a
> conflict.  For ioremapped ranges, WB is tracked in the same way as other
> cache types.  Hence, WB->new is considered as a conflict.
>
> In my previous testing, 2) was undetected since 1) led using a fake
> physical address which was not tracked for WB.  This made ioremapped
> ranges worked just like RAM. :-(
>
> Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
> set_memory_xyz is already slow, but this makes it even slower, though.
>
> For 2), WB has to be continuously tracked in order to detect aliasing,
> ex. ioremap_cache and ioremap to a same address.  So, I think
> reserve_memtype() needs the following changes:
>  - Add a new arg to see if an operation is to create a new mapping or to
> change cache attribute.
>  - Track overlapping maps so that cache type change to an overlapping
> range can be detected and failed.
>
> This level of changes requires a separate set of patches if we pursue to
> support ioremapped ranges.  So, I am considering to take one of the two
> options below.
>
> A) Drop the patch for set_memory_wt.
>
> B) Keep the patch for set_memory_wt, but document that it fails with
> -EINVAL and its use is for RAM only.
>

I vote A.  I see no great reason to add code that can't be used.  Once
someone needs this ability, they can add it :)

It's too bad that ioremap is called ioremap and not iomap.  Otherwise
the natural solution would be to add a different function call
ioremap_wt that's like set_memory_wt but for ioremap ranges.  Calling
it ioreremap_wt sounds kind of disgusting :)

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

On Mon, 2014-09-15 at 18:22 -0700, Andy Lutomirski wrote:
> On Mon, Sep 15, 2014 at 2:19 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
> >> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
> >> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> >> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> >> > >> > +a specific range to wt with set_memory_wt.
> >> > >>
> >> > >> That's mighty specific :)
> >> > >
> >> > > How about below?
> >> > >
> >> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
> >> >
> >> > Do they have to be cached?
> >>
> >> Yes, set_memory_xyz only supports WB->type->WB transition.
> >>
> >> > How about:
> >> >
> >> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
> >> > there is no need to change the memory type back before calling
> >> > iounmap.
> >> >
> >> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
> >>
> >> Sounds good.  Yes, I will use cashed ioremapped ranges.
> >
> > Well, testing "no need to change the memory type back before calling
> > iounmap" turns out to be a good test case.  I realized that
> > set_memory_xyz only works properly for RAM.  There are two problems for
> > using this interface for ioremapped ranges.
> >
> > 1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
> > __pa() translates the addr into a fake physical address when it is an
> > ioremapped address.
> >
> > 2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
> > state is managed untracked.  Hence, WB->new->WB is not considered as a
> > conflict.  For ioremapped ranges, WB is tracked in the same way as other
> > cache types.  Hence, WB->new is considered as a conflict.
> >
> > In my previous testing, 2) was undetected since 1) led using a fake
> > physical address which was not tracked for WB.  This made ioremapped
> > ranges worked just like RAM. :-(
> >
> > Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
> > set_memory_xyz is already slow, but this makes it even slower, though.
> >
> > For 2), WB has to be continuously tracked in order to detect aliasing,
> > ex. ioremap_cache and ioremap to a same address.  So, I think
> > reserve_memtype() needs the following changes:
> >  - Add a new arg to see if an operation is to create a new mapping or to
> > change cache attribute.
> >  - Track overlapping maps so that cache type change to an overlapping
> > range can be detected and failed.
> >
> > This level of changes requires a separate set of patches if we pursue to
> > support ioremapped ranges.  So, I am considering to take one of the two
> > options below.
> >
> > A) Drop the patch for set_memory_wt.
> >
> > B) Keep the patch for set_memory_wt, but document that it fails with
> > -EINVAL and its use is for RAM only.
> >
> 
> I vote A.  I see no great reason to add code that can't be used.  Once
> someone needs this ability, they can add it :)

Agreed.  I will drop the patch for now.  Since _PGMT_WB does not seem to
be used for tracking WB, we might be able to use this bit for WT.  But I
need to look at the code more carefully for sure.

> It's too bad that ioremap is called ioremap and not iomap.  Otherwise
> the natural solution would be to add a different function call
> ioremap_wt that's like set_memory_wt but for ioremap ranges.  Calling
> it ioreremap_wt sounds kind of disgusting :)

:)

Thanks,
-Toshi

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

On Mon, 2014-09-15 at 18:22 -0700, Andy Lutomirski wrote:
> On Mon, Sep 15, 2014 at 2:19 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
> >> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
> >> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> >> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> >> > >> > +a specific range to wt with set_memory_wt.
> >> > >>
> >> > >> That's mighty specific :)
> >> > >
> >> > > How about below?
> >> > >
> >> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
> >> >
> >> > Do they have to be cached?
> >>
> >> Yes, set_memory_xyz only supports WB->type->WB transition.
> >>
> >> > How about:
> >> >
> >> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
> >> > there is no need to change the memory type back before calling
> >> > iounmap.
> >> >
> >> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
> >>
> >> Sounds good.  Yes, I will use cashed ioremapped ranges.
> >
> > Well, testing "no need to change the memory type back before calling
> > iounmap" turns out to be a good test case.  I realized that
> > set_memory_xyz only works properly for RAM.  There are two problems for
> > using this interface for ioremapped ranges.
> >
> > 1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
> > __pa() translates the addr into a fake physical address when it is an
> > ioremapped address.
> >
> > 2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
> > state is managed untracked.  Hence, WB->new->WB is not considered as a
> > conflict.  For ioremapped ranges, WB is tracked in the same way as other
> > cache types.  Hence, WB->new is considered as a conflict.
> >
> > In my previous testing, 2) was undetected since 1) led using a fake
> > physical address which was not tracked for WB.  This made ioremapped
> > ranges worked just like RAM. :-(
> >
> > Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
> > set_memory_xyz is already slow, but this makes it even slower, though.
> >
> > For 2), WB has to be continuously tracked in order to detect aliasing,
> > ex. ioremap_cache and ioremap to a same address.  So, I think
> > reserve_memtype() needs the following changes:
> >  - Add a new arg to see if an operation is to create a new mapping or to
> > change cache attribute.
> >  - Track overlapping maps so that cache type change to an overlapping
> > range can be detected and failed.
> >
> > This level of changes requires a separate set of patches if we pursue to
> > support ioremapped ranges.  So, I am considering to take one of the two
> > options below.
> >
> > A) Drop the patch for set_memory_wt.
> >
> > B) Keep the patch for set_memory_wt, but document that it fails with
> > -EINVAL and its use is for RAM only.
> >
> 
> I vote A.  I see no great reason to add code that can't be used.  Once
> someone needs this ability, they can add it :)

Agreed.  I will drop the patch for now.  Since _PGMT_WB does not seem to
be used for tracking WB, we might be able to use this bit for WT.  But I
need to look at the code more carefully for sure.

> It's too bad that ioremap is called ioremap and not iomap.  Otherwise
> the natural solution would be to add a different function call
> ioremap_wt that's like set_memory_wt but for ioremap ranges.  Calling
> it ioreremap_wt sounds kind of disgusting :)

:)

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Yigal Korman]

Perhaps your patch is still valid in the context of this patch:
https://lkml.org/lkml/2014/9/9/612
Part of the reason for creating it was the fact that ioremap is using
a fake virtual address mapping.
So I think we can still use set_memory_wt for memory created with
add_persistent_memory.
What do you think?

Also, a thought: maybe the driver that will be managing the memory
added by add_persistent_memory should be responsible for resolving
aliasing issues.

Thanks,
Yigal

On Tue, Sep 16, 2014 at 7:52 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Mon, 2014-09-15 at 18:22 -0700, Andy Lutomirski wrote:
>> On Mon, Sep 15, 2014 at 2:19 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
>> >> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
>> >> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> >> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
>> >> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>> >> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
>> >> > >> > +a specific range to wt with set_memory_wt.
>> >> > >>
>> >> > >> That's mighty specific :)
>> >> > >
>> >> > > How about below?
>> >> > >
>> >> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
>> >> >
>> >> > Do they have to be cached?
>> >>
>> >> Yes, set_memory_xyz only supports WB->type->WB transition.
>> >>
>> >> > How about:
>> >> >
>> >> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
>> >> > there is no need to change the memory type back before calling
>> >> > iounmap.
>> >> >
>> >> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
>> >>
>> >> Sounds good.  Yes, I will use cashed ioremapped ranges.
>> >
>> > Well, testing "no need to change the memory type back before calling
>> > iounmap" turns out to be a good test case.  I realized that
>> > set_memory_xyz only works properly for RAM.  There are two problems for
>> > using this interface for ioremapped ranges.
>> >
>> > 1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
>> > __pa() translates the addr into a fake physical address when it is an
>> > ioremapped address.
>> >
>> > 2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
>> > state is managed untracked.  Hence, WB->new->WB is not considered as a
>> > conflict.  For ioremapped ranges, WB is tracked in the same way as other
>> > cache types.  Hence, WB->new is considered as a conflict.
>> >
>> > In my previous testing, 2) was undetected since 1) led using a fake
>> > physical address which was not tracked for WB.  This made ioremapped
>> > ranges worked just like RAM. :-(
>> >
>> > Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
>> > set_memory_xyz is already slow, but this makes it even slower, though.
>> >
>> > For 2), WB has to be continuously tracked in order to detect aliasing,
>> > ex. ioremap_cache and ioremap to a same address.  So, I think
>> > reserve_memtype() needs the following changes:
>> >  - Add a new arg to see if an operation is to create a new mapping or to
>> > change cache attribute.
>> >  - Track overlapping maps so that cache type change to an overlapping
>> > range can be detected and failed.
>> >
>> > This level of changes requires a separate set of patches if we pursue to
>> > support ioremapped ranges.  So, I am considering to take one of the two
>> > options below.
>> >
>> > A) Drop the patch for set_memory_wt.
>> >
>> > B) Keep the patch for set_memory_wt, but document that it fails with
>> > -EINVAL and its use is for RAM only.
>> >
>>
>> I vote A.  I see no great reason to add code that can't be used.  Once
>> someone needs this ability, they can add it :)
>
> Agreed.  I will drop the patch for now.  Since _PGMT_WB does not seem to
> be used for tracking WB, we might be able to use this bit for WT.  But I
> need to look at the code more carefully for sure.
>
>> It's too bad that ioremap is called ioremap and not iomap.  Otherwise
>> the natural solution would be to add a different function call
>> ioremap_wt that's like set_memory_wt but for ioremap ranges.  Calling
>> it ioreremap_wt sounds kind of disgusting :)
>
> :)
>
> Thanks,
> -Toshi
>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Yigal Korman]

Perhaps your patch is still valid in the context of this patch:
https://lkml.org/lkml/2014/9/9/612
Part of the reason for creating it was the fact that ioremap is using
a fake virtual address mapping.
So I think we can still use set_memory_wt for memory created with
add_persistent_memory.
What do you think?

Also, a thought: maybe the driver that will be managing the memory
added by add_persistent_memory should be responsible for resolving
aliasing issues.

Thanks,
Yigal

On Tue, Sep 16, 2014 at 7:52 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Mon, 2014-09-15 at 18:22 -0700, Andy Lutomirski wrote:
>> On Mon, Sep 15, 2014 at 2:19 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
>> >> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
>> >> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
>> >> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
>> >> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>> >> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
>> >> > >> > +a specific range to wt with set_memory_wt.
>> >> > >>
>> >> > >> That's mighty specific :)
>> >> > >
>> >> > > How about below?
>> >> > >
>> >> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
>> >> >
>> >> > Do they have to be cached?
>> >>
>> >> Yes, set_memory_xyz only supports WB->type->WB transition.
>> >>
>> >> > How about:
>> >> >
>> >> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
>> >> > there is no need to change the memory type back before calling
>> >> > iounmap.
>> >> >
>> >> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
>> >>
>> >> Sounds good.  Yes, I will use cashed ioremapped ranges.
>> >
>> > Well, testing "no need to change the memory type back before calling
>> > iounmap" turns out to be a good test case.  I realized that
>> > set_memory_xyz only works properly for RAM.  There are two problems for
>> > using this interface for ioremapped ranges.
>> >
>> > 1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
>> > __pa() translates the addr into a fake physical address when it is an
>> > ioremapped address.
>> >
>> > 2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
>> > state is managed untracked.  Hence, WB->new->WB is not considered as a
>> > conflict.  For ioremapped ranges, WB is tracked in the same way as other
>> > cache types.  Hence, WB->new is considered as a conflict.
>> >
>> > In my previous testing, 2) was undetected since 1) led using a fake
>> > physical address which was not tracked for WB.  This made ioremapped
>> > ranges worked just like RAM. :-(
>> >
>> > Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
>> > set_memory_xyz is already slow, but this makes it even slower, though.
>> >
>> > For 2), WB has to be continuously tracked in order to detect aliasing,
>> > ex. ioremap_cache and ioremap to a same address.  So, I think
>> > reserve_memtype() needs the following changes:
>> >  - Add a new arg to see if an operation is to create a new mapping or to
>> > change cache attribute.
>> >  - Track overlapping maps so that cache type change to an overlapping
>> > range can be detected and failed.
>> >
>> > This level of changes requires a separate set of patches if we pursue to
>> > support ioremapped ranges.  So, I am considering to take one of the two
>> > options below.
>> >
>> > A) Drop the patch for set_memory_wt.
>> >
>> > B) Keep the patch for set_memory_wt, but document that it fails with
>> > -EINVAL and its use is for RAM only.
>> >
>>
>> I vote A.  I see no great reason to add code that can't be used.  Once
>> someone needs this ability, they can add it :)
>
> Agreed.  I will drop the patch for now.  Since _PGMT_WB does not seem to
> be used for tracking WB, we might be able to use this bit for WT.  But I
> need to look at the code more carefully for sure.
>
>> It's too bad that ioremap is called ioremap and not iomap.  Otherwise
>> the natural solution would be to add a different function call
>> ioremap_wt that's like set_memory_wt but for ioremap ranges.  Calling
>> it ioreremap_wt sounds kind of disgusting :)
>
> :)
>
> Thanks,
> -Toshi
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

On Wed, 2014-09-17 at 00:45 +0300, Yigal Korman wrote:
> Perhaps your patch is still valid in the context of this patch:
> https://lkml.org/lkml/2014/9/9/612
> Part of the reason for creating it was the fact that ioremap is using
> a fake virtual address mapping.
> So I think we can still use set_memory_wt for memory created with
> add_persistent_memory.
> What do you think?

Yes, I am aware of the work.  I agree that it will address issue 1), but
we still have issue 2).  Since this work will create page tables, we may
be able to treat NV-DIMM ranges as RAM for reservation.  However, we
also have an issue with RAM that set_page_memtype() needs additional bit
to track WT type.  I am hoping that _PGMT_WB can be redefined for WT,
but I need to check it more carefully.  Considering the risk of such
changes, this will be a separate item. 

> Also, a thought: maybe the driver that will be managing the memory
> added by add_persistent_memory should be responsible for resolving
> aliasing issues.

Yes, that's one way to do it.  Under the current design, though,
reserve_memtype() should work to detect aliasing for supported
use-cases.

Thanks,
-Toshi


> 
> Thanks,
> Yigal
> 
> On Tue, Sep 16, 2014 at 7:52 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Mon, 2014-09-15 at 18:22 -0700, Andy Lutomirski wrote:
> >> On Mon, Sep 15, 2014 at 2:19 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
> >> >> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
> >> >> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> >> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> >> >> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> >> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> >> >> > >> > +a specific range to wt with set_memory_wt.
> >> >> > >>
> >> >> > >> That's mighty specific :)
> >> >> > >
> >> >> > > How about below?
> >> >> > >
> >> >> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
> >> >> >
> >> >> > Do they have to be cached?
> >> >>
> >> >> Yes, set_memory_xyz only supports WB->type->WB transition.
> >> >>
> >> >> > How about:
> >> >> >
> >> >> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
> >> >> > there is no need to change the memory type back before calling
> >> >> > iounmap.
> >> >> >
> >> >> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
> >> >>
> >> >> Sounds good.  Yes, I will use cashed ioremapped ranges.
> >> >
> >> > Well, testing "no need to change the memory type back before calling
> >> > iounmap" turns out to be a good test case.  I realized that
> >> > set_memory_xyz only works properly for RAM.  There are two problems for
> >> > using this interface for ioremapped ranges.
> >> >
> >> > 1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
> >> > __pa() translates the addr into a fake physical address when it is an
> >> > ioremapped address.
> >> >
> >> > 2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
> >> > state is managed untracked.  Hence, WB->new->WB is not considered as a
> >> > conflict.  For ioremapped ranges, WB is tracked in the same way as other
> >> > cache types.  Hence, WB->new is considered as a conflict.
> >> >
> >> > In my previous testing, 2) was undetected since 1) led using a fake
> >> > physical address which was not tracked for WB.  This made ioremapped
> >> > ranges worked just like RAM. :-(
> >> >
> >> > Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
> >> > set_memory_xyz is already slow, but this makes it even slower, though.
> >> >
> >> > For 2), WB has to be continuously tracked in order to detect aliasing,
> >> > ex. ioremap_cache and ioremap to a same address.  So, I think
> >> > reserve_memtype() needs the following changes:
> >> >  - Add a new arg to see if an operation is to create a new mapping or to
> >> > change cache attribute.
> >> >  - Track overlapping maps so that cache type change to an overlapping
> >> > range can be detected and failed.
> >> >
> >> > This level of changes requires a separate set of patches if we pursue to
> >> > support ioremapped ranges.  So, I am considering to take one of the two
> >> > options below.
> >> >
> >> > A) Drop the patch for set_memory_wt.
> >> >
> >> > B) Keep the patch for set_memory_wt, but document that it fails with
> >> > -EINVAL and its use is for RAM only.
> >> >
> >>
> >> I vote A.  I see no great reason to add code that can't be used.  Once
> >> someone needs this ability, they can add it :)
> >
> > Agreed.  I will drop the patch for now.  Since _PGMT_WB does not seem to
> > be used for tracking WB, we might be able to use this bit for WT.  But I
> > need to look at the code more carefully for sure.
> >
> >> It's too bad that ioremap is called ioremap and not iomap.  Otherwise
> >> the natural solution would be to add a different function call
> >> ioremap_wt that's like set_memory_wt but for ioremap ranges.  Calling
> >> it ioreremap_wt sounds kind of disgusting :)
> >
> > :)
> >
> > Thanks,
> > -Toshi
> >

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Toshi Kani]

On Wed, 2014-09-17 at 00:45 +0300, Yigal Korman wrote:
> Perhaps your patch is still valid in the context of this patch:
> https://lkml.org/lkml/2014/9/9/612
> Part of the reason for creating it was the fact that ioremap is using
> a fake virtual address mapping.
> So I think we can still use set_memory_wt for memory created with
> add_persistent_memory.
> What do you think?

Yes, I am aware of the work.  I agree that it will address issue 1), but
we still have issue 2).  Since this work will create page tables, we may
be able to treat NV-DIMM ranges as RAM for reservation.  However, we
also have an issue with RAM that set_page_memtype() needs additional bit
to track WT type.  I am hoping that _PGMT_WB can be redefined for WT,
but I need to check it more carefully.  Considering the risk of such
changes, this will be a separate item. 

> Also, a thought: maybe the driver that will be managing the memory
> added by add_persistent_memory should be responsible for resolving
> aliasing issues.

Yes, that's one way to do it.  Under the current design, though,
reserve_memtype() should work to detect aliasing for supported
use-cases.

Thanks,
-Toshi


> 
> Thanks,
> Yigal
> 
> On Tue, Sep 16, 2014 at 7:52 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Mon, 2014-09-15 at 18:22 -0700, Andy Lutomirski wrote:
> >> On Mon, Sep 15, 2014 at 2:19 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
> >> >> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
> >> >> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> >> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> >> >> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> >> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> >> >> > >> > +a specific range to wt with set_memory_wt.
> >> >> > >>
> >> >> > >> That's mighty specific :)
> >> >> > >
> >> >> > > How about below?
> >> >> > >
> >> >> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
> >> >> >
> >> >> > Do they have to be cached?
> >> >>
> >> >> Yes, set_memory_xyz only supports WB->type->WB transition.
> >> >>
> >> >> > How about:
> >> >> >
> >> >> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
> >> >> > there is no need to change the memory type back before calling
> >> >> > iounmap.
> >> >> >
> >> >> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
> >> >>
> >> >> Sounds good.  Yes, I will use cashed ioremapped ranges.
> >> >
> >> > Well, testing "no need to change the memory type back before calling
> >> > iounmap" turns out to be a good test case.  I realized that
> >> > set_memory_xyz only works properly for RAM.  There are two problems for
> >> > using this interface for ioremapped ranges.
> >> >
> >> > 1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
> >> > __pa() translates the addr into a fake physical address when it is an
> >> > ioremapped address.
> >> >
> >> > 2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
> >> > state is managed untracked.  Hence, WB->new->WB is not considered as a
> >> > conflict.  For ioremapped ranges, WB is tracked in the same way as other
> >> > cache types.  Hence, WB->new is considered as a conflict.
> >> >
> >> > In my previous testing, 2) was undetected since 1) led using a fake
> >> > physical address which was not tracked for WB.  This made ioremapped
> >> > ranges worked just like RAM. :-(
> >> >
> >> > Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
> >> > set_memory_xyz is already slow, but this makes it even slower, though.
> >> >
> >> > For 2), WB has to be continuously tracked in order to detect aliasing,
> >> > ex. ioremap_cache and ioremap to a same address.  So, I think
> >> > reserve_memtype() needs the following changes:
> >> >  - Add a new arg to see if an operation is to create a new mapping or to
> >> > change cache attribute.
> >> >  - Track overlapping maps so that cache type change to an overlapping
> >> > range can be detected and failed.
> >> >
> >> > This level of changes requires a separate set of patches if we pursue to
> >> > support ioremapped ranges.  So, I am considering to take one of the two
> >> > options below.
> >> >
> >> > A) Drop the patch for set_memory_wt.
> >> >
> >> > B) Keep the patch for set_memory_wt, but document that it fails with
> >> > -EINVAL and its use is for RAM only.
> >> >
> >>
> >> I vote A.  I see no great reason to add code that can't be used.  Once
> >> someone needs this ability, they can add it :)
> >
> > Agreed.  I will drop the patch for now.  Since _PGMT_WB does not seem to
> > be used for tracking WB, we might be able to use this bit for WT.  But I
> > need to look at the code more carefully for sure.
> >
> >> It's too bad that ioremap is called ioremap and not iomap.  Otherwise
> >> the natural solution would be to add a different function call
> >> ioremap_wt that's like set_memory_wt but for ioremap ranges.  Calling
> >> it ioreremap_wt sounds kind of disgusting :)
> >
> > :)
> >
> > Thanks,
> > -Toshi
> >


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>