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

[PATCH 0/5] 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/8/26/61

All new/modified interfaces have been tested.

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

---
 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                    | 73 +++++++++++++++++++++++++++---------
 include/asm-generic/io.h             |  4 ++
 include/asm-generic/iomap.h          |  4 ++
 include/asm-generic/pgtable.h        |  4 ++
 9 files changed, 172 insertions(+), 25 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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

This patch sets WT to the PA4 slot in the PAT MSR when the processor
is not affected by the PAT errata.  The upper 4 slots of the PAT MSR
are continued to be unused on the following Intel processors.

  errata           cpuid
  --------------------------------------
  Pentium 2, A52   family 0x6, model 0x5
  Pentium 3, E27   family 0x6, model 0x7
  Pentium M, Y26   family 0x6, model 0x9
  Pentium 4, N46   family 0xf, model 0x0

For these affected 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 |   47 ++++++++++++++++++++++++++++++++---------------
 1 file changed, 32 insertions(+), 15 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index feb4d30..b1891dc 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -132,6 +132,7 @@ void pat_init(void)
 {
 	u64 pat;
 	bool boot_cpu = !boot_pat_state;
+	struct cpuinfo_x86 *c = &boot_cpu_data;
 
 	if (!pat_enabled)
 		return;
@@ -152,21 +153,37 @@ 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 == 0x5) ||
+	       (c->x86_model == 0x7) ||
+	       (c->x86_model == 0x9))) ||
+	     ((c->x86 == 0xf) && (c->x86_model == 0x0)))) {
+		/*
+		 * Upper four PAT entries are not usable on the following
+		 * Intel processors.
+		 *
+		 *   errata           cpuid
+		 *   --------------------------------------
+		 *   Pentium 2, A52   family 0x6, model 0x5
+		 *   Pentium 3, E27   family 0x6, model 0x7
+		 *   Pentium M, Y26   family 0x6, model 0x9
+		 *   Pentium 4, N46   family 0xf, model 0x0
+		 *
+		 * 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 {
+		/*
+		 * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4:WT, 5-7:reserved
+		 */
+		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
+		      PAT(4, WT) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
+	}
 
 	/* 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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Henrique de Moraes Holschuh]

On Thu, 04 Sep 2014, Toshi Kani wrote:
> This patch sets WT to the PA4 slot in the PAT MSR when the processor
> is not affected by the PAT errata.  The upper 4 slots of the PAT MSR
> are continued to be unused on the following Intel processors.
> 
>   errata           cpuid
>   --------------------------------------
>   Pentium 2, A52   family 0x6, model 0x5
>   Pentium 3, E27   family 0x6, model 0x7
>   Pentium M, Y26   family 0x6, model 0x9
>   Pentium 4, N46   family 0xf, model 0x0
> 
> For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC-
> per the default setup in __cachemode2pte_tbl[].

There are at least two PAT errata.  The blacklist is in
arch/x86/kernel/cpu/intel.c:

        if (c->x86 == 6 && c->x86_model < 15)
                clear_cpu_cap(c, X86_FEATURE_PAT);

It covers model 13, which is not in your blacklist.

It *is* possible that PAT would work on model 13, as I don't think it has
any PAT errata listed and it was blacklisted "just in case" (from memory. I
did not re-check), but this is untested, and unwise to enable on an aging
platform.

I am worried of uncharted territory, here.  I'd actually advocate for not
enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
is using them as well.  Is this a real concern, or am I being overly
cautious?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

--
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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[H. Peter Anvin]

On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote:
> 
> I am worried of uncharted territory, here.  I'd actually advocate for not
> enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
> is using them as well.  Is this a real concern, or am I being overly
> cautious?
> 

It is extremely unlikely that we'd have PAT issues in 32-bit mode and
not in 64-bit mode on the same CPU.

As far as I know, the current blacklist rule is very conservative due to
lack of testing more than anything else.

	-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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Henrique de Moraes Holschuh]

On Thu, 04 Sep 2014, H. Peter Anvin wrote:
> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote:
> > I am worried of uncharted territory, here.  I'd actually advocate for not
> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
> > is using them as well.  Is this a real concern, or am I being overly
> > cautious?
> 
> It is extremely unlikely that we'd have PAT issues in 32-bit mode and
> not in 64-bit mode on the same CPU.

Sure, but is it really a good idea to enable this on the *old* non-64-bit
capable processors (note: I don't mean x86-64 processors operating in 32-bit
mode) ?

> As far as I know, the current blacklist rule is very conservative due to
> lack of testing more than anything else.

I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted
from using PAT :-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

--
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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Andy Lutomirski]

On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> On Thu, 04 Sep 2014, H. Peter Anvin wrote:
>> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote:
>> > I am worried of uncharted territory, here.  I'd actually advocate for not
>> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
>> > is using them as well.  Is this a real concern, or am I being overly
>> > cautious?
>>
>> It is extremely unlikely that we'd have PAT issues in 32-bit mode and
>> not in 64-bit mode on the same CPU.
>
> Sure, but is it really a good idea to enable this on the *old* non-64-bit
> capable processors (note: I don't mean x86-64 processors operating in 32-bit
> mode) ?
>
>> As far as I know, the current blacklist rule is very conservative due to
>> lack of testing more than anything else.
>
> I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted
> from using PAT :-)

At the very least, anyone who plugs an NV-DIMM into a 32-bit machine
is nuts, and not just because I'd be somewhat amazed if it even
physically fits into the slot. :)

--Andy

>
> --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh



-- 
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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

On Thu, 2014-09-04 at 16:34 -0700, Andy Lutomirski wrote:
> On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> wrote:
> > On Thu, 04 Sep 2014, H. Peter Anvin wrote:
> >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote:
> >> > I am worried of uncharted territory, here.  I'd actually advocate for not
> >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
> >> > is using them as well.  Is this a real concern, or am I being overly
> >> > cautious?
> >>
> >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and
> >> not in 64-bit mode on the same CPU.
> >
> > Sure, but is it really a good idea to enable this on the *old* non-64-bit
> > capable processors (note: I don't mean x86-64 processors operating in 32-bit
> > mode) ?
> >
> >> As far as I know, the current blacklist rule is very conservative due to
> >> lack of testing more than anything else.
> >
> > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted
> > from using PAT :-)
> 
> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine
> is nuts, and not just because I'd be somewhat amazed if it even
> physically fits into the slot. :)

According to the spec, the upper four entries bug was fixed in Pentium 4
model 0x1.  So, the remaining Intel 32-bit processors that may enable
the upper four entries are Pentium 4 model 0x1-4.  Should we disable it
for all Pentium 4 models?

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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Andy Lutomirski]

On Thu, Sep 4, 2014 at 5:29 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Thu, 2014-09-04 at 16:34 -0700, Andy Lutomirski wrote:
>> On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh
>> <hmh@hmh.eng.br> wrote:
>> > On Thu, 04 Sep 2014, H. Peter Anvin wrote:
>> >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote:
>> >> > I am worried of uncharted territory, here.  I'd actually advocate for not
>> >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
>> >> > is using them as well.  Is this a real concern, or am I being overly
>> >> > cautious?
>> >>
>> >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and
>> >> not in 64-bit mode on the same CPU.
>> >
>> > Sure, but is it really a good idea to enable this on the *old* non-64-bit
>> > capable processors (note: I don't mean x86-64 processors operating in 32-bit
>> > mode) ?
>> >
>> >> As far as I know, the current blacklist rule is very conservative due to
>> >> lack of testing more than anything else.
>> >
>> > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted
>> > from using PAT :-)
>>
>> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine
>> is nuts, and not just because I'd be somewhat amazed if it even
>> physically fits into the slot. :)
>
> According to the spec, the upper four entries bug was fixed in Pentium 4
> model 0x1.  So, the remaining Intel 32-bit processors that may enable
> the upper four entries are Pentium 4 model 0x1-4.  Should we disable it
> for all Pentium 4 models?

Assuming that this is Pentium 4 erratum N46, then there may be another
option: use slot 7 instead of slot 4 for WT.  Then, even if somehow
the blacklist screws up, the worst that happens is that a WT page gets
interpreted as UC.  I suppose this could cause aliasing issues, but
can't cause problems for people who don't use the high entries in the
first place.

--Andy

>
> 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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

On Thu, 2014-09-04 at 17:51 -0700, Andy Lutomirski wrote:
> On Thu, Sep 4, 2014 at 5:29 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Thu, 2014-09-04 at 16:34 -0700, Andy Lutomirski wrote:
> >> On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh
> >> <hmh@hmh.eng.br> wrote:
> >> > On Thu, 04 Sep 2014, H. Peter Anvin wrote:
> >> >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote:
> >> >> > I am worried of uncharted territory, here.  I'd actually advocate for not
> >> >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
> >> >> > is using them as well.  Is this a real concern, or am I being overly
> >> >> > cautious?
> >> >>
> >> >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and
> >> >> not in 64-bit mode on the same CPU.
> >> >
> >> > Sure, but is it really a good idea to enable this on the *old* non-64-bit
> >> > capable processors (note: I don't mean x86-64 processors operating in 32-bit
> >> > mode) ?
> >> >
> >> >> As far as I know, the current blacklist rule is very conservative due to
> >> >> lack of testing more than anything else.
> >> >
> >> > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted
> >> > from using PAT :-)
> >>
> >> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine
> >> is nuts, and not just because I'd be somewhat amazed if it even
> >> physically fits into the slot. :)
> >
> > According to the spec, the upper four entries bug was fixed in Pentium 4
> > model 0x1.  So, the remaining Intel 32-bit processors that may enable
> > the upper four entries are Pentium 4 model 0x1-4.  Should we disable it
> > for all Pentium 4 models?
> 
> Assuming that this is Pentium 4 erratum N46, then there may be another
> option: use slot 7 instead of slot 4 for WT.  Then, even if somehow
> the blacklist screws up, the worst that happens is that a WT page gets
> interpreted as UC.  I suppose this could cause aliasing issues, but
> can't cause problems for people who don't use the high entries in the
> first place.

That's a fine idea, but as Ingo also suggested, I am going to disable
this feature on all Pentium 4 models.  That should give us a safety
margin.  Using slot 4 has a benefit that it keeps the PAT setup
consistent with Xen.      

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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[H. Peter Anvin]

On 09/05/2014 07:00 AM, Toshi Kani wrote:
> 
> That's a fine idea, but as Ingo also suggested, I am going to disable
> this feature on all Pentium 4 models.  That should give us a safety
> margin.  Using slot 4 has a benefit that it keeps the PAT setup
> consistent with Xen.      
> 

Slot 4 is also the maximally problematic one, because it is the one that
might be incorrectly invoked for the page tables themselves.

	-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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote:
> On 09/05/2014 07:00 AM, Toshi Kani wrote:
> > 
> > That's a fine idea, but as Ingo also suggested, I am going to disable
> > this feature on all Pentium 4 models.  That should give us a safety
> > margin.  Using slot 4 has a benefit that it keeps the PAT setup
> > consistent with Xen.      
> > 
> 
> Slot 4 is also the maximally problematic one, because it is the one that
> might be incorrectly invoked for the page tables themselves.

Good point.  I wonder if Xen folks feel strongly about keeping the PAT
setup consistent with the kernel.  If not, we may choose to use slot 6
(or 7).

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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[H. Peter Anvin]

On 09/05/2014 08:22 AM, Toshi Kani wrote:
> On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote:
>> On 09/05/2014 07:00 AM, Toshi Kani wrote:
>>>
>>> That's a fine idea, but as Ingo also suggested, I am going to disable
>>> this feature on all Pentium 4 models.  That should give us a safety
>>> margin.  Using slot 4 has a benefit that it keeps the PAT setup
>>> consistent with Xen.      
>>>
>>
>> Slot 4 is also the maximally problematic one, because it is the one that
>> might be incorrectly invoked for the page tables themselves.
> 
> Good point.  I wonder if Xen folks feel strongly about keeping the PAT
> setup consistent with the kernel.  If not, we may choose to use slot 6
> (or 7).
> 

Who cares what the Xen folks "feel strongly about"?  If strong feelings
were a design criterion Xen support would have been pulled from the
kernel a long, long time ago.

The important thing is how to design for the situation that we currently
have to live with.

	-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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

On Fri, 2014-09-05 at 08:41 -0700, H. Peter Anvin wrote:
> On 09/05/2014 08:22 AM, Toshi Kani wrote:
> > On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote:
> >> On 09/05/2014 07:00 AM, Toshi Kani wrote:
> >>>
> >>> That's a fine idea, but as Ingo also suggested, I am going to disable
> >>> this feature on all Pentium 4 models.  That should give us a safety
> >>> margin.  Using slot 4 has a benefit that it keeps the PAT setup
> >>> consistent with Xen.      
> >>>
> >>
> >> Slot 4 is also the maximally problematic one, because it is the one that
> >> might be incorrectly invoked for the page tables themselves.
> > 
> > Good point.  I wonder if Xen folks feel strongly about keeping the PAT
> > setup consistent with the kernel.  If not, we may choose to use slot 6
> > (or 7).
> > 
> 
> Who cares what the Xen folks "feel strongly about"?  If strong feelings
> were a design criterion Xen support would have been pulled from the
> kernel a long, long time ago.
> 
> The important thing is how to design for the situation that we currently
> have to live with.

I see.  Then, I am going to use slot 7 for WT as suggested by Andy.  I
think it is the safest slot as slot 3 is UC and is not currently used.

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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Konrad Rzeszutek Wilk]

On Thu, Sep 04, 2014 at 04:34:43PM -0700, Andy Lutomirski wrote:
> On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> wrote:
> > On Thu, 04 Sep 2014, H. Peter Anvin wrote:
> >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote:
> >> > I am worried of uncharted territory, here.  I'd actually advocate for not
> >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
> >> > is using them as well.  Is this a real concern, or am I being overly
> >> > cautious?
> >>
> >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and
> >> not in 64-bit mode on the same CPU.
> >
> > Sure, but is it really a good idea to enable this on the *old* non-64-bit
> > capable processors (note: I don't mean x86-64 processors operating in 32-bit
> > mode) ?
> >
> >> As far as I know, the current blacklist rule is very conservative due to
> >> lack of testing more than anything else.
> >
> > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted
> > from using PAT :-)
> 
> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine
> is nuts, and not just because I'd be somewhat amazed if it even
> physically fits into the slot. :)

They do have PCIe to PCI adapters, so you _could_ do it :-)

> 
> --Andy
> 
> >
> > --
> >   "One disk to rule them all, One disk to find them. One disk to bring
> >   them all and in the darkness grind them. In the Land of Redmond
> >   where the shadows lie." -- The Silicon Valley Tarot
> >   Henrique Holschuh
> 
> 
> 
> -- 
> 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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Andy Lutomirski]

On Fri, Sep 12, 2014 at 12:25 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Thu, Sep 04, 2014 at 04:34:43PM -0700, Andy Lutomirski wrote:
>> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine
>> is nuts, and not just because I'd be somewhat amazed if it even
>> physically fits into the slot. :)
>
> They do have PCIe to PCI adapters, so you _could_ do it :-)
>

My NV-DIMMs are DDR3 RDIMMs, so it would be a very magical adapter indeed.

--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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Konrad Rzeszutek Wilk]

On Fri, Sep 12, 2014 at 01:03:12PM -0700, Andy Lutomirski wrote:
> On Fri, Sep 12, 2014 at 12:25 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Thu, Sep 04, 2014 at 04:34:43PM -0700, Andy Lutomirski wrote:
> >> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine
> >> is nuts, and not just because I'd be somewhat amazed if it even
> >> physically fits into the slot. :)
> >
> > They do have PCIe to PCI adapters, so you _could_ do it :-)
> >
> 
> My NV-DIMMs are DDR3 RDIMMs, so it would be a very magical adapter indeed.

I misread that as 'NVME', duh!

> 
> --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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 04 Sep 2014, Toshi Kani wrote:
> > This patch sets WT to the PA4 slot in the PAT MSR when the processor
> > is not affected by the PAT errata.  The upper 4 slots of the PAT MSR
> > are continued to be unused on the following Intel processors.
> > 
> >   errata           cpuid
> >   --------------------------------------
> >   Pentium 2, A52   family 0x6, model 0x5
> >   Pentium 3, E27   family 0x6, model 0x7
> >   Pentium M, Y26   family 0x6, model 0x9
> >   Pentium 4, N46   family 0xf, model 0x0
> > 
> > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC-
> > per the default setup in __cachemode2pte_tbl[].
> 
> There are at least two PAT errata.  The blacklist is in
> arch/x86/kernel/cpu/intel.c:
> 
>         if (c->x86 == 6 && c->x86_model < 15)
>                 clear_cpu_cap(c, X86_FEATURE_PAT);
> 
> It covers model 13, which is not in your blacklist.
> 
> It *is* possible that PAT would work on model 13, as I don't think it has
> any PAT errata listed and it was blacklisted "just in case" (from memory. I
> did not re-check), but this is untested, and unwise to enable on an aging
> platform.
> 
> I am worried of uncharted territory, here.  I'd actually advocate for not
> enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
> is using them as well.  Is this a real concern, or am I being overly
> cautious?

The blacklist you pointed out covers a different PAT errata, and is
still effective after this change.  pat_init() will call pat_disable()
and the PAT will continue to be disabled on these processors.  There is
no change for them.

My blacklist covers the PAT errata that makes the upper four bit
unusable when the PAT is enabled.

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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Andy Lutomirski]

On Thu, Sep 4, 2014 at 1:31 PM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote:
>> On Thu, 04 Sep 2014, Toshi Kani wrote:
>> > This patch sets WT to the PA4 slot in the PAT MSR when the processor
>> > is not affected by the PAT errata.  The upper 4 slots of the PAT MSR
>> > are continued to be unused on the following Intel processors.
>> >
>> >   errata           cpuid
>> >   --------------------------------------
>> >   Pentium 2, A52   family 0x6, model 0x5
>> >   Pentium 3, E27   family 0x6, model 0x7
>> >   Pentium M, Y26   family 0x6, model 0x9
>> >   Pentium 4, N46   family 0xf, model 0x0
>> >
>> > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC-
>> > per the default setup in __cachemode2pte_tbl[].
>>
>> There are at least two PAT errata.  The blacklist is in
>> arch/x86/kernel/cpu/intel.c:
>>
>>         if (c->x86 == 6 && c->x86_model < 15)
>>                 clear_cpu_cap(c, X86_FEATURE_PAT);
>>
>> It covers model 13, which is not in your blacklist.
>>
>> It *is* possible that PAT would work on model 13, as I don't think it has
>> any PAT errata listed and it was blacklisted "just in case" (from memory. I
>> did not re-check), but this is untested, and unwise to enable on an aging
>> platform.
>>
>> I am worried of uncharted territory, here.  I'd actually advocate for not
>> enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
>> is using them as well.  Is this a real concern, or am I being overly
>> cautious?
>
> The blacklist you pointed out covers a different PAT errata, and is
> still effective after this change.  pat_init() will call pat_disable()
> and the PAT will continue to be disabled on these processors.  There is
> no change for them.
>
> My blacklist covers the PAT errata that makes the upper four bit
> unusable when the PAT is enabled.
>

IIRC a lot of the errata only matter if we try to use various PAT bits
in intermediate page table entries to change the caching mode of, say,
the PTE pages.  If we're doing that, something's very wrong, errata or
otherwise.

--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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

On Thu, 2014-09-04 at 14:31 -0600, Toshi Kani wrote:
> On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote:
> > On Thu, 04 Sep 2014, Toshi Kani wrote:
> > > This patch sets WT to the PA4 slot in the PAT MSR when the processor
> > > is not affected by the PAT errata.  The upper 4 slots of the PAT MSR
> > > are continued to be unused on the following Intel processors.
> > > 
> > >   errata           cpuid
> > >   --------------------------------------
> > >   Pentium 2, A52   family 0x6, model 0x5
> > >   Pentium 3, E27   family 0x6, model 0x7
> > >   Pentium M, Y26   family 0x6, model 0x9
> > >   Pentium 4, N46   family 0xf, model 0x0
> > > 
> > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC-
> > > per the default setup in __cachemode2pte_tbl[].
> > 
> > There are at least two PAT errata.  The blacklist is in
> > arch/x86/kernel/cpu/intel.c:
> > 
> >         if (c->x86 == 6 && c->x86_model < 15)
> >                 clear_cpu_cap(c, X86_FEATURE_PAT);
> > 
> > It covers model 13, which is not in your blacklist.
> > 
> > It *is* possible that PAT would work on model 13, as I don't think it has
> > any PAT errata listed and it was blacklisted "just in case" (from memory. I
> > did not re-check), but this is untested, and unwise to enable on an aging
> > platform.
> > 
> > I am worried of uncharted territory, here.  I'd actually advocate for not
> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
> > is using them as well.  Is this a real concern, or am I being overly
> > cautious?
> 
> The blacklist you pointed out covers a different PAT errata, and is
> still effective after this change.  pat_init() will call pat_disable()
> and the PAT will continue to be disabled on these processors.  There is
> no change for them.
> 
> My blacklist covers the PAT errata that makes the upper four bit
> unusable when the PAT is enabled.

I checked more carefully, and it turns out that the processors that have
the WC bug with PAT/MTRR also have the upper four bit bug in PAT as
well.  The updated blacklist is:

   errata               cpuid
   --------------------------------------
   Pentium 2, A52       family 0x6, model 0x5
   Pentium 3, E27       family 0x6, model 0x7, 0x8
   Pentium 3 Xeon, 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
                
So, the check can be the same as cpu/intel.c, except that early Pentium
4 steppings also have the upper four bit bug.  I will update the check.
In any case, this check is only meaningful for P4 since the PAT is
disabled for P2/3/M. 

Thanks Henrique for pointing this out!
-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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Ingo Molnar]

* Toshi Kani <toshi.kani@hp.com> wrote:

> On Thu, 2014-09-04 at 14:31 -0600, Toshi Kani wrote:
> > On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote:
> > > On Thu, 04 Sep 2014, Toshi Kani wrote:
> > > > This patch sets WT to the PA4 slot in the PAT MSR when the processor
> > > > is not affected by the PAT errata.  The upper 4 slots of the PAT MSR
> > > > are continued to be unused on the following Intel processors.
> > > > 
> > > >   errata           cpuid
> > > >   --------------------------------------
> > > >   Pentium 2, A52   family 0x6, model 0x5
> > > >   Pentium 3, E27   family 0x6, model 0x7
> > > >   Pentium M, Y26   family 0x6, model 0x9
> > > >   Pentium 4, N46   family 0xf, model 0x0
> > > > 
> > > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC-
> > > > per the default setup in __cachemode2pte_tbl[].
> > > 
> > > There are at least two PAT errata.  The blacklist is in
> > > arch/x86/kernel/cpu/intel.c:
> > > 
> > >         if (c->x86 == 6 && c->x86_model < 15)
> > >                 clear_cpu_cap(c, X86_FEATURE_PAT);
> > > 
> > > It covers model 13, which is not in your blacklist.
> > > 
> > > It *is* possible that PAT would work on model 13, as I don't think it has
> > > any PAT errata listed and it was blacklisted "just in case" (from memory. I
> > > did not re-check), but this is untested, and unwise to enable on an aging
> > > platform.
> > > 
> > > I am worried of uncharted territory, here.  I'd actually advocate for not
> > > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
> > > is using them as well.  Is this a real concern, or am I being overly
> > > cautious?
> > 
> > The blacklist you pointed out covers a different PAT errata, and is
> > still effective after this change.  pat_init() will call pat_disable()
> > and the PAT will continue to be disabled on these processors.  There is
> > no change for them.
> > 
> > My blacklist covers the PAT errata that makes the upper four bit
> > unusable when the PAT is enabled.
> 
> I checked more carefully, and it turns out that the processors 
> that have the WC bug with PAT/MTRR also have the upper four bit 
> bug in PAT as well.  The updated blacklist is:
> 
>    errata               cpuid
>    --------------------------------------
>    Pentium 2, A52       family 0x6, model 0x5
>    Pentium 3, E27       family 0x6, model 0x7, 0x8
>    Pentium 3 Xeon, 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
>                 
> So, the check can be the same as cpu/intel.c, except that early 
> Pentium 4 steppings also have the upper four bit bug.  I will 
> update the check. In any case, this check is only meaningful 
> for P4 since the PAT is disabled for P2/3/M.

Any reason why we have to create such a sharp boundary, instead 
of simply saying: 'disable PAT on all x86 CPU families that have 
at least one buggy model'?

That would nicely sort out all the broken CPUs, and would make it 
highly unlikely that we'd accidentally forget about a model or 
two.

Thanks,

	Ingo

--
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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Toshi Kani]

On Fri, 2014-09-05 at 12:23 +0200, Ingo Molnar wrote:
> * Toshi Kani <toshi.kani@hp.com> wrote:
> 
> > On Thu, 2014-09-04 at 14:31 -0600, Toshi Kani wrote:
> > > On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote:
> > > > On Thu, 04 Sep 2014, Toshi Kani wrote:
> > > > > This patch sets WT to the PA4 slot in the PAT MSR when the processor
> > > > > is not affected by the PAT errata.  The upper 4 slots of the PAT MSR
> > > > > are continued to be unused on the following Intel processors.
> > > > > 
> > > > >   errata           cpuid
> > > > >   --------------------------------------
> > > > >   Pentium 2, A52   family 0x6, model 0x5
> > > > >   Pentium 3, E27   family 0x6, model 0x7
> > > > >   Pentium M, Y26   family 0x6, model 0x9
> > > > >   Pentium 4, N46   family 0xf, model 0x0
> > > > > 
> > > > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC-
> > > > > per the default setup in __cachemode2pte_tbl[].
> > > > 
> > > > There are at least two PAT errata.  The blacklist is in
> > > > arch/x86/kernel/cpu/intel.c:
> > > > 
> > > >         if (c->x86 == 6 && c->x86_model < 15)
> > > >                 clear_cpu_cap(c, X86_FEATURE_PAT);
> > > > 
> > > > It covers model 13, which is not in your blacklist.
> > > > 
> > > > It *is* possible that PAT would work on model 13, as I don't think it has
> > > > any PAT errata listed and it was blacklisted "just in case" (from memory. I
> > > > did not re-check), but this is untested, and unwise to enable on an aging
> > > > platform.
> > > > 
> > > > I am worried of uncharted territory, here.  I'd actually advocate for not
> > > > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP
> > > > is using them as well.  Is this a real concern, or am I being overly
> > > > cautious?
> > > 
> > > The blacklist you pointed out covers a different PAT errata, and is
> > > still effective after this change.  pat_init() will call pat_disable()
> > > and the PAT will continue to be disabled on these processors.  There is
> > > no change for them.
> > > 
> > > My blacklist covers the PAT errata that makes the upper four bit
> > > unusable when the PAT is enabled.
> > 
> > I checked more carefully, and it turns out that the processors 
> > that have the WC bug with PAT/MTRR also have the upper four bit 
> > bug in PAT as well.  The updated blacklist is:
> > 
> >    errata               cpuid
> >    --------------------------------------
> >    Pentium 2, A52       family 0x6, model 0x5
> >    Pentium 3, E27       family 0x6, model 0x7, 0x8
> >    Pentium 3 Xeon, 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
> >                 
> > So, the check can be the same as cpu/intel.c, except that early 
> > Pentium 4 steppings also have the upper four bit bug.  I will 
> > update the check. In any case, this check is only meaningful 
> > for P4 since the PAT is disabled for P2/3/M.
> 
> Any reason why we have to create such a sharp boundary, instead 
> of simply saying: 'disable PAT on all x86 CPU families that have 
> at least one buggy model'?
> 
> That would nicely sort out all the broken CPUs, and would make it 
> highly unlikely that we'd accidentally forget about a model or 
> two.

Agreed.  I will disable this feature on all Pentium 4 models as well.  I
do not think there is any necessity to enable it on Pentium 4.

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 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR

[Henrique de Moraes Holschuh]

On Fri, 05 Sep 2014, Toshi Kani wrote:
> On Fri, 2014-09-05 at 12:23 +0200, Ingo Molnar wrote:
> > Any reason why we have to create such a sharp boundary, instead 
> > of simply saying: 'disable PAT on all x86 CPU families that have 
> > at least one buggy model'?
> > 
> > That would nicely sort out all the broken CPUs, and would make it 
> > highly unlikely that we'd accidentally forget about a model or 
> > two.
> 
> Agreed.  I will disable this feature on all Pentium 4 models as well.  I
> do not think there is any necessity to enable it on Pentium 4.

Thank you.  That takes care of my misguivings about enabling this on aging
platforms as well.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

--
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 2/5] 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 b1891dc..87b21dd 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -271,6 +271,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
@@ -282,6 +284,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);
@@ -331,6 +340,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
@@ -350,10 +360,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 3/5] 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>

[PATCH 4/5] 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 reserve_memtype() only supports WT for non-RAM ranges
at this point.

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 4/5] x86, mm: Add set_memory_wt() for WT

[Andy Lutomirski]

On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> This patch adds set_memory_wt(), set_memory_array_wt(), and
> set_pages_array_wt() for setting range(s) of memory to WT.
>

Possibly dumb question: I thought that set_memory_xyz was only for
RAM.  Is that incorrect?

--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 4/5] x86, mm: Add set_memory_wt() for WT

[Toshi Kani]

On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote:
> On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> > This patch adds set_memory_wt(), set_memory_array_wt(), and
> > set_pages_array_wt() for setting range(s) of memory to WT.
> >
> 
> Possibly dumb question: I thought that set_memory_xyz was only for
> RAM.  Is that incorrect?

It works for non-RAM ranges as well.  For instance, you can use
set_memory_xyz() to change cache attribute for a non-RAM range mapped by
ioremap_cache().

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 4/5] x86, mm: Add set_memory_wt() for WT

[Andy Lutomirski]

On Thu, Sep 4, 2014 at 11:57 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote:
>> On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>> > This patch adds set_memory_wt(), set_memory_array_wt(), and
>> > set_pages_array_wt() for setting range(s) of memory to WT.
>> >
>>
>> Possibly dumb question: I thought that set_memory_xyz was only for
>> RAM.  Is that incorrect?
>
> It works for non-RAM ranges as well.  For instance, you can use
> set_memory_xyz() to change cache attribute for a non-RAM range mapped by
> ioremap_cache().

OK -- I didn't realize that was legal.

Do you, by any chance, have a test driver for this?  For example,
something that lets your reserve some WT memory at boot and mmap it?
I wouldn't mind getting some benchmarks, and I can even throw it at
the NV-DIMM box that's sitting under my desk :)

--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 4/5] x86, mm: Add set_memory_wt() for WT

[Toshi Kani]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

On Thu, 2014-09-04 at 12:14 -0700, Andy Lutomirski wrote:
> On Thu, Sep 4, 2014 at 11:57 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote:
> >> On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> >> > This patch adds set_memory_wt(), set_memory_array_wt(), and
> >> > set_pages_array_wt() for setting range(s) of memory to WT.
> >> >
> >>
> >> Possibly dumb question: I thought that set_memory_xyz was only for
> >> RAM.  Is that incorrect?
> >
> > It works for non-RAM ranges as well.  For instance, you can use
> > set_memory_xyz() to change cache attribute for a non-RAM range mapped by
> > ioremap_cache().
> 
> OK -- I didn't realize that was legal.
> 
> Do you, by any chance, have a test driver for this?  For example,
> something that lets your reserve some WT memory at boot and mmap it?
> I wouldn't mind getting some benchmarks, and I can even throw it at
> the NV-DIMM box that's sitting under my desk :)

Yes, the attached file contains two test tools.  Please update
NVDIMM_ADDR to your NV-DIMM address in test-wt.c and test.c.

1) mmap via /dev/mem
dev-mem-test/mem-wt.patch - kernel patch that tweaks /dev/mem
dev-mem-test/test-wt.c - user program that mmaps a NVDIMM range w/ WT

2) Test driver for testing the interfaces
interfaces-test/Makefile
interfaces-test/test.c

Thanks,
-Toshi

[-- Attachment #2: tests.tgz --]
[-- Type: application/x-compressed-tar, Size: 2454 bytes --]

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

[Yigal Korman]

I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt
If it's possible, can you please update pat.txt as part of the patch?

Thank you,
Yigal

On 04/09/2014 21:57, Toshi Kani wrote:
> On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote:
>> On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani <toshi.kani@hp.com> wrote:
>>> This patch adds set_memory_wt(), set_memory_array_wt(), and
>>> set_pages_array_wt() for setting range(s) of memory to WT.
>>>
>> Possibly dumb question: I thought that set_memory_xyz was only for
>> RAM.  Is that incorrect?
> It works for non-RAM ranges as well.  For instance, you can use
> set_memory_xyz() to change cache attribute for a non-RAM range mapped by
> ioremap_cache().
>
> Thanks,
> -Toshi
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
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 4/5] x86, mm: Add set_memory_wt() for WT

[Andy Lutomirski]

On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman <yigal@plexistor.com> wrote:
> I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt
> If it's possible, can you please update pat.txt as part of the patch?

Indeed.  That file seems to indicate several times that the intended
use of set_memory_xyz is for RAM.

--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 4/5] x86, mm: Add set_memory_wt() for WT

[Toshi Kani]

On Sun, 2014-09-07 at 09:49 -0700, Andy Lutomirski wrote:
> On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman <yigal@plexistor.com> wrote:
> > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt
> > If it's possible, can you please update pat.txt as part of the patch?
> 
> Indeed.  That file seems to indicate several times that the intended
> use of set_memory_xyz is for RAM.


Good point.  pat.txt is correct that the "intended" use of
set_memory_xyz() is for RAM since there is no other way to set non-WB
attribute for RAM.  For reserved memory, one should call ioremap_xyz()
to map with the xyz attribute directly.  From the functionality POV,
set_memory_xyz() works for reserved memory, but such usage is not
intended.

Should I drop the patch 4/5 until we can track the use of WT for RAM?

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 4/5] x86, mm: Add set_memory_wt() for WT

[Andy Lutomirski]

On Sep 8, 2014 8:18 AM, "Toshi Kani" <toshi.kani@hp.com> wrote:
>
> On Sun, 2014-09-07 at 09:49 -0700, Andy Lutomirski wrote:
> > On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman <yigal@plexistor.com> wrote:
> > > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt
> > > If it's possible, can you please update pat.txt as part of the patch?
> >
> > Indeed.  That file seems to indicate several times that the intended
> > use of set_memory_xyz is for RAM.
>
>
> Good point.  pat.txt is correct that the "intended" use of
> set_memory_xyz() is for RAM since there is no other way to set non-WB
> attribute for RAM.  For reserved memory, one should call ioremap_xyz()
> to map with the xyz attribute directly.  From the functionality POV,
> set_memory_xyz() works for reserved memory, but such usage is not
> intended.
>
> Should I drop the patch 4/5 until we can track the use of WT for RAM?

Probably not.  I can imagine someone ioremapping a huge chunk of
NV-DIMM and then wanting to change some of it to WT.  Unless I've
missed something (which is rather likely), the cleanest way to do this
is with set_memory_wt.

If that happens, someone should update pat.txt to indicate that it's allowed.

--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 4/5] x86, mm: Add set_memory_wt() for WT

[Toshi Kani]

On Mon, 2014-09-08 at 10:23 -0700, Andy Lutomirski wrote:
> On Sep 8, 2014 8:18 AM, "Toshi Kani" <toshi.kani@hp.com> wrote:
> >
> > On Sun, 2014-09-07 at 09:49 -0700, Andy Lutomirski wrote:
> > > On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman <yigal@plexistor.com> wrote:
> > > > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt
> > > > If it's possible, can you please update pat.txt as part of the patch?
> > >
> > > Indeed.  That file seems to indicate several times that the intended
> > > use of set_memory_xyz is for RAM.
> >
> >
> > Good point.  pat.txt is correct that the "intended" use of
> > set_memory_xyz() is for RAM since there is no other way to set non-WB
> > attribute for RAM.  For reserved memory, one should call ioremap_xyz()
> > to map with the xyz attribute directly.  From the functionality POV,
> > set_memory_xyz() works for reserved memory, but such usage is not
> > intended.
> >
> > Should I drop the patch 4/5 until we can track the use of WT for RAM?
> 
> Probably not.  I can imagine someone ioremapping a huge chunk of
> NV-DIMM and then wanting to change some of it to WT.  Unless I've
> missed something (which is rather likely), the cleanest way to do this
> is with set_memory_wt.

Yeah, that sounds possible.

> If that happens, someone should update pat.txt to indicate that it's allowed.

Since it is unlikely that someone will update pat.txt later, I will
update it to:

-------------------------------------------------------------------
API                    |    RAM   |  ACPI,...  |  Reserved/Holes  |

-----------------------|----------|------------|------------------|
set_memory_wt          |    *1    |    --      |       WT         |
 set_memory_wb         |          |            |                  |


*1: -EINVAL due to the current limitation in reserve_memtype().


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>

[PATCH 5/5] 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 87b21dd..ed62ead 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -878,6 +878,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>