Re: pat support in the kernel

Re: pat support in the kernel

[Andi Kleen]

Terence Ripperda <tripperda@nvidia.com> writes:

> Hello all,
>
> I've discussed adding Page Attribute Table (PAT) support to the kernel w/ a few developers offline. They were very supportive and suggested I bring the discussion to lkml so others could get involved.

change_page_attr() will already do it for the kernel mappings. Just
define a PAGE_KERNEL_WC. Drawback is that it will convert the mapping
to 4K pages (from 2/4MB), but there is probably no alternative unless
all your mappings are 2MB aligned.

But the tricky part of it is that you need to make sure all mappings
to that memory have the same caching attribute, otherwise you invoke
undefined x86 behaviour and risk cache corruptions on some CPUs. 

For the special case of AGP it's quite simple - when an user process maps
the aperture it can just set the correct bits in its own mmap method 
like it already does for uncachable mappings. But for other mappings
it is more difficult. 

For normal memory you would need to find a way to synchronize the
attributes in all mappers (e.g. setting a flag in struct page or
similar). For frame buffer you also need to handle it in all mmap'ers
(like fbcon or /dev/mem). I think handling these generic cases will
need a few VM changes.

[actually even the agp aperture can be accessed using /dev/mem, 
but thats probably unlikely to happen because there is a better interface 
and could be ignored]

-Andi

Re: pat support in the kernel

[Terence Ripperda, tripperda]

On Tue, May 20, 2003 at 09:10:18PM +0200, ak@muc.de wrote:
> change_page_attr() will already do it for the kernel mappings. Just
> define a PAGE_KERNEL_WC.

correct. that was the intent.

> But the tricky part of it is that you need to make sure all mappings
> to that memory have the same caching attribute, otherwise you invoke
> undefined x86 behaviour and risk cache corruptions on some CPUs. 

yes. implementing the basic PAT support is pretty trivial. it's dealing with these cache attribute issues that is the hard part. 

> For normal memory you would need to find a way to synchronize the
> attributes in all mappers (e.g. setting a flag in struct page or
> similar).

are you refering to generic memory that might have shared mappings between multiple processes? I had really only thought of memory explicitly allocated by a driver and mapped to a process, in which this wouldn't be an issue (or is an issue isolated to the specific driver).

it seems it would be easy enough to add a flag to struct page indicating that any future mappings of this memory must be marked with the given attribute. But you'd need to also worry about previous mappings of that page. wouldn't that require a fairly exhaustive scan of who has the physical memory mapped?

would it make sense to limit this functionality to memory mmapped with MAP_PRIVATE rather than MAP_SHARED?

what if process 1 mapped a region WC, forcing process 2 to later map it the same way even though process 2 doesn't care. then process 1 exits and process 3 decides to map the memory. does the caching attribute remain sticky with process 2 (causing process 3 to also need the memory WC), or revert to cached/whatever when the requestor's mapping is removed?

what if 2 processes ask for conflicting mappings? process 1 wants the framebuffer mapped WC, but process 2 asks for it cacheable. or process 1 maps 1/2 of the framebuffer WC and process 2 asks for the full framebuffer uncached.

a lot of these are corner cases that are unlikely to be desirable, but probably should be protected against.

> For frame buffer you also need to handle it in all mmap'ers
> (like fbcon or /dev/mem). I think handling these generic cases will
> need a few VM changes.

yes, this was the case I was more worried about, but it looks like the case above will have the same issues.

I don't think there's any way currently to determine if anyone already has a mapping to a given address range. And it seems that scanning for pre-existing mappings would be pretty ugly. are there any other suggestions for how to handle this?

Thanks,
Terence

Re: pat support in the kernel

[Andi Kleen]

On Tue, May 20, 2003 at 10:18:55PM +0200, Terence Ripperda wrote:
> > For normal memory you would need to find a way to synchronize the
> > attributes in all mappers (e.g. setting a flag in struct page or
> > similar).
> 
> are you refering to generic memory that might have shared mappings between multiple processes? I had really only thought of memory explicitly allocated by a driver and mapped to a process, in which this wouldn't be an issue (or is an issue isolated to the specific driver).

Yes.

> 
> it seems it would be easy enough to add a flag to struct page indicating that any future mappings of this memory must be marked with the given attribute. But you'd need to also worry about previous mappings of that page. wouldn't that require a fairly exhaustive scan of who has the physical memory mapped?

Not in 2.5 - it has the new RMAP vm with backlinks from struct page to ptes.
I already used that in a new machine check handler that has similar requirements.

> 
> would it make sense to limit this functionality to memory mmapped with MAP_PRIVATE rather than MAP_SHARED?

That would be a bit ugly, but possible if there is no better way.

> 
> what if process 1 mapped a region WC, forcing process 2 to later map it the same way even though process 2 doesn't care. then process 1 exits and process 3 decides to map the memory. does the caching attribute remain sticky with process 2 (causing process 3 to also need the memory WC), or revert to cached/whatever when the requestor's mapping is removed?

You have to walk the rmap chains and change the ptes, or return -EINVAL.

(e.g. you could define the API that only transition from writeback to other mappings
is allowed or reversal) 

The locking of this is a bit tricky however.

> 
> what if 2 processes ask for conflicting mappings? process 1 wants the framebuffer mapped WC, but process 2 asks for it cacheable. or process 1 maps 1/2 of the framebuffer WC and process 2 asks for the full framebuffer uncached.

One of them has to lose. Or use the EINVAL method above.

> 
> a lot of these are corner cases that are unlikely to be desirable, but probably should be protected against.

Yes, definitely.

> > For frame buffer you also need to handle it in all mmap'ers
> > (like fbcon or /dev/mem). I think handling these generic cases will
> > need a few VM changes.
> 
> yes, this was the case I was more worried about, but it looks like the case above will have the same issues.

The problem is that the frame buffer and the agp aperture normally have no struct page,
so you need to find a different way to store the shared state for them (e.g. a new
rbtree)

> 
> I don't think there's any way currently to determine if anyone already has a mapping to a given address range. And it seems that scanning for pre-existing mappings would be pretty ugly. are there any other suggestions for how to handle this?

In 2.4 there isn't, unless you run a RMAP kernel.

In 2.5 it's easy.

-Andi

Re: pat support in the kernel

[Terence Ripperda, tripperda]

Thanks for the tips Andi,

The rmap lookups sound like a good route to go. I'll work on that and post another patch when I have something working. 

And I agree that a "first come, first serve" approach that fails any conflicting mapping attempts is a good route to go.

Terence

Re: pat support in the kernel

[Andi Kleen]

mikpe@csd.uu.se writes:

> (Large pages ignoring PAT index bit 2, or something like that.)

change_page_attr will force 4K pages for these anyways, so for the kernel
direct mapping it should not be an issue. 

For the hugetlbfs user mapping you may need to check the case, but
it's probably reasonable to EINVAL there.

Other than that everything should be 4K mapped.

-Andi

Re: pat support in the kernel

[mikpe]

Andi Kleen writes:
 > mikpe@csd.uu.se writes:
 > 
 > > (Large pages ignoring PAT index bit 2, or something like that.)
 > 
 > change_page_attr will force 4K pages for these anyways, so for the kernel
 > direct mapping it should not be an issue. 
 > 
 > For the hugetlbfs user mapping you may need to check the case, but
 > it's probably reasonable to EINVAL there.
 > 
 > Other than that everything should be 4K mapped.

The bug is that 4K pages get the wrong PAT index; the large page
thing is the trigger but the large pages themselves arent' affected.

So 4K pages need to be restricted to the low 4 PAT types.

Re: pat support in the kernel

[Andi Kleen]

On Wed, 21 May 2003 12:12:43 +0200
mikpe@csd.uu.se wrote:

> Andi Kleen writes:
>  > mikpe@csd.uu.se writes:
>  > 
>  > > (Large pages ignoring PAT index bit 2, or something like that.)
>  > 
>  > change_page_attr will force 4K pages for these anyways, so for the kernel
>  > direct mapping it should not be an issue. 
>  > 
>  > For the hugetlbfs user mapping you may need to check the case, but
>  > it's probably reasonable to EINVAL there.
>  > 
>  > Other than that everything should be 4K mapped.
> 
> The bug is that 4K pages get the wrong PAT index; the large page
> thing is the trigger but the large pages themselves arent' affected.
> 
> So 4K pages need to be restricted to the low 4 PAT types.

Should be no issue. cache disabled and write combining seem to be the
only really useful caching types anyways. You don't even need to mess
with the PAT registers for them, the default 486/586 compatible WC and CD PTE
bits should work.

-Andi

pat support in the kernel

[Terence Ripperda, tripperda]

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

Hello all,

I've discussed adding Page Attribute Table (PAT) support to the kernel w/ a few developers offline. They were very supportive and suggested I bring the discussion to lkml so others could get involved.

PAT support allows setting cache attributes via the virtual page table entries that are traditionally set via the MTRRs. The specific cache attribute graphics companies such as ourselves (nvidia), ATI, Matrox, and others are becoming interested in is Write-Combining (WC), both for the AGP and framebuffer apertures. Traditionally, these apertures are marked WC by setting the physical memory ranges to WC in the MTRRs. This has traditionally worked very well, but is becoming a problem with workstation systems with 1+ Gigs of memory. 

The problem here is that the system bios typically covers physical ram with Write-Back (WB) MTRRs. On systems with large amounts of physical ram, especially when physical memory ranges can intersperse with ram, the bioses are using multiple MTRRs with strange results. In some cases, enough MTRRs are used to cover physical ram, such that MTRRs are not left over for the AGP or framebuffer apertures. In other cases, 1 MTRR is used to mark non-physical ram as Uncached (which covers both apertures). When trying to mark the appropriate apertures as WC, the kernel refuses to overlap the MTRRs.

Windows works around this MTRR issue by using the PATs.

An example of such a report recently sent to lkml is here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0303.1/0606.html

I discussed this some with Jeff Hartmann, who had some initial development code that was integrated into agpgart, for marking agp pages WC as they were allocated. I think it would be preferable to have pat support seperate from agpgart. In that way, other drivers could make use of PAT support for other means (such as mapping the framebuffer). Jeff Hartmann sent us a pass at adding PAT support to agpgart. We've modified his code slightly to be more generic (standalone from agpgart) and usable via the traditional __pgprot() macros (and therefore with the change_page_attr() function).

Please cc me on any responses, as I'm not on the list.

Thanks,
Terence



[-- Attachment #2: linux-2.4.20-pat.diff --]
[-- Type: text/plain, Size: 9994 bytes --]

diff -ruN linux-2.4.20/arch/i386/config.in linux-2.4.20-pat/arch/i386/config.in
--- linux-2.4.20/arch/i386/config.in	2002-11-28 15:53:09.000000000 -0800
+++ linux-2.4.20-pat/arch/i386/config.in	2003-03-24 11:16:28.000000000 -0800
@@ -103,6 +103,7 @@
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
    define_bool CONFIG_X86_PPRO_FENCE y
    define_bool CONFIG_X86_F00F_WORKS_OK y
+   define_bool CONFIG_X86_PAT y
 fi
 if [ "$CONFIG_MPENTIUMIII" = "y" ]; then
    define_int  CONFIG_X86_L1_CACHE_SHIFT 5
@@ -111,6 +112,7 @@
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
    define_bool CONFIG_X86_F00F_WORKS_OK y
+   define_bool CONFIG_X86_PAT y
 fi
 if [ "$CONFIG_MPENTIUM4" = "y" ]; then
    define_int  CONFIG_X86_L1_CACHE_SHIFT 7
@@ -119,6 +121,7 @@
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
    define_bool CONFIG_X86_F00F_WORKS_OK y
+   define_bool CONFIG_X86_PAT y
 fi
 if [ "$CONFIG_MK6" = "y" ]; then
    define_int  CONFIG_X86_L1_CACHE_SHIFT 5
@@ -134,6 +137,7 @@
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
    define_bool CONFIG_X86_F00F_WORKS_OK y
+   define_bool CONFIG_X86_PAT y
 fi
 if [ "$CONFIG_MELAN" = "y" ]; then
    define_int  CONFIG_X86_L1_CACHE_SHIFT 4
diff -ruN linux-2.4.20/arch/i386/kernel/Makefile linux-2.4.20-pat/arch/i386/kernel/Makefile
--- linux-2.4.20/arch/i386/kernel/Makefile	2002-11-28 15:53:09.000000000 -0800
+++ linux-2.4.20-pat/arch/i386/kernel/Makefile	2003-03-24 12:23:23.000000000 -0800
@@ -40,5 +40,6 @@
 obj-$(CONFIG_X86_LOCAL_APIC)	+= mpparse.o apic.o nmi.o
 obj-$(CONFIG_X86_IO_APIC)	+= io_apic.o acpitable.o
 obj-$(CONFIG_X86_VISWS_APIC)	+= visws_apic.o
+obj-$(CONFIG_X86_PAT)	+= pat.o
 
 include $(TOPDIR)/Rules.make
diff -ruN linux-2.4.20/arch/i386/kernel/pat.c linux-2.4.20-pat/arch/i386/kernel/pat.c
--- linux-2.4.20/arch/i386/kernel/pat.c	1969-12-31 16:00:00.000000000 -0800
+++ linux-2.4.20-pat/arch/i386/kernel/pat.c	2003-03-24 13:42:20.000000000 -0800
@@ -0,0 +1,97 @@
+/*
+ * x86 PAT support.
+ * Copyright (C) 2003 Jeff Hartmann.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * JEFF HARTMANN, DAVE JONES, OR ANY OTHER CONTRIBUTORS BE LIABLE FOR ANY
+ * CLAIM,  DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
+ * OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE 
+ * OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Very losely based on code I wrote at VA Linux Systems in 2001.
+ *
+ * That code had the following copyright notice:
+ * Copyright (C) 2001 Jeff Hartmann
+ * Copyright (C) VA Linux Systems, Inc., Fremont, California.
+ */
+
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/pagemap.h>
+#include <linux/miscdevice.h>
+#include <linux/pm.h>
+#include <linux/vmalloc.h>
+#include <asm/bitops.h>
+#include <asm/io.h>
+#include <asm/msr.h>
+#include <asm/cpufeature.h>
+#include <asm/system.h>
+#include <asm/pat.h>
+
+static void set_pat(void)
+{
+	switch(boot_cpu_data.x86_vendor) {
+	case X86_VENDOR_AMD:
+		wrmsr(IA32_CR_PAT,
+		      AMD_PAT_31_0,
+		      AMD_PAT_63_32);
+		break;
+	case X86_VENDOR_INTEL:
+		wrmsr(IA32_CR_PAT,
+		      INTEL_PAT_31_0,
+		      INTEL_PAT_63_32);
+		break;
+	default:
+		printk("Unknown vendor in set_pat\n");
+		BUG();
+	}
+}
+
+/* Very similar behavior to mtrr setup */
+static void pat_ipi_handler(void *null)
+{
+	unsigned long flags = 0, cr4val = 0, cr0val = 0;
+
+    __save_flags(flags); __cli();
+    if (test_bit(X86_FEATURE_PGE, &boot_cpu_data.x86_capability)) {
+		cr4val = read_cr4();
+		write_cr4(cr4val & (unsigned char) ~(1<<7));
+	}
+	cr0val = read_cr0() | (1<<30);
+	wbinvd();
+	write_cr0(cr0val);
+	wbinvd();
+	/* Okay everything is ready */
+
+	set_pat();
+
+	/* Reenable the caches */
+	wbinvd();
+	write_cr0(read_cr0() & ~(1<<30));
+    if (test_bit(X86_FEATURE_PGE, &boot_cpu_data.x86_capability)) {
+		write_cr4(cr4val);
+    }
+    __restore_flags(flags);
+}
+
+void __init pat_global_setup(void)
+{
+#ifdef CONFIG_SMP
+	if (smp_call_function(pat_ipi_handler, NULL, 1, 1) != 0)
+		panic("pat: timed out waiting for the other CPUs!\n");
+#endif
+	pat_ipi_handler(NULL);
+}
+
Binary files linux-2.4.20/include/asm-i386/.pat.h.swp and linux-2.4.20-pat/include/asm-i386/.pat.h.swp differ
diff -ruN linux-2.4.20/include/asm-i386/pat.h linux-2.4.20-pat/include/asm-i386/pat.h
--- linux-2.4.20/include/asm-i386/pat.h	1969-12-31 16:00:00.000000000 -0800
+++ linux-2.4.20-pat/include/asm-i386/pat.h	2003-03-24 13:44:20.000000000 -0800
@@ -0,0 +1,78 @@
+/*
+ * x86 PAT support.
+ * Copyright (C) 2003 Jeff Hartmann.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * JEFF HARTMANN, DAVE JONES, OR ANY OTHER CONTRIBUTORS BE LIABLE FOR ANY
+ * CLAIM,  DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
+ * OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE 
+ * OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Very losely based on code I wrote at VA Linux Systems in 2001.
+ *
+ * That code had the following copyright notice:
+ * Copyright (C) 2001 Jeff Hartmann
+ * Copyright (C) VA Linux Systems, Inc., Fremont, California.
+ */
+
+#ifndef _LINUX_PAT_H
+#define _LINUX_PAT_H
+
+#define PAT_UNCACHEABLE 	0
+#define PAT_WRITE_COMB		1
+#define PAT_WRITE_THRGH 	4
+#define PAT_WRITE_PROT		5
+#define PAT_WRITE_BACK		6
+#define PAT_UNCACHED		7
+
+/* Here is the PAT's default layout on ia32 cpus when we are done.
+ * PAT0: Write Back
+ * PAT1: Write Combine
+ * PAT2: Uncached
+ * PAT3: Uncacheable
+ * PAT4: Write Through
+ * PAT5: Write Protect
+ * PAT6: Uncached
+ * PAT7: Uncacheable
+ *
+ * Note: On Athlon cpus PAT2/PAT3 & PAT6/PAT7 are both Uncacheable since 
+ *	 there is no uncached type.
+ */
+#define AMD_PAT_31_0		((PAT_WRITE_BACK) | \
+				 (PAT_WRITE_COMB << 8) | \
+				 (PAT_UNCACHEABLE << 16) | \
+				 (PAT_UNCACHEABLE << 24))
+#define AMD_PAT_63_32		((PAT_WRITE_THRGH) | \
+				 (PAT_WRITE_PROT << 8) | \
+				 (PAT_UNCACHEABLE << 16) | \
+				 (PAT_UNCACHEABLE << 24))
+
+#define INTEL_PAT_31_0		((PAT_WRITE_BACK) | \
+				 (PAT_WRITE_COMB << 8) | \
+				 (PAT_UNCACHED << 16) | \
+				 (PAT_UNCACHEABLE << 24))
+
+#define INTEL_PAT_63_32		((PAT_WRITE_THRGH) | \
+				 (PAT_WRITE_PROT << 8) | \
+				 (PAT_UNCACHED << 16) | \
+				 (PAT_UNCACHEABLE << 24))
+
+#define IA32_CR_PAT		0x277
+
+/* This function is intended for PAT initialization only! */
+extern void pat_global_setup(void);
+
+#endif /*  _LINUX_PAT_H  */
+
diff -ruN linux-2.4.20/include/asm-i386/pgtable.h linux-2.4.20-pat/include/asm-i386/pgtable.h
--- linux-2.4.20/include/asm-i386/pgtable.h	2002-11-28 15:53:15.000000000 -0800
+++ linux-2.4.20-pat/include/asm-i386/pgtable.h	2003-03-24 13:23:45.000000000 -0800
@@ -194,6 +194,9 @@
 #define _PAGE_PSE	0x080	/* 4 MB (or 2MB) page, Pentium+, if present.. */
 #define _PAGE_GLOBAL	0x100	/* Global TLB entry PPro+ */
 
+/* Added define for write combining page, only valid if pat enabled. */
+#define _PAGE_WRTCOMB  _PAGE_PWT
+
 #define _PAGE_PROTNONE	0x080	/* If not present */
 
 #define _PAGE_TABLE	(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED | _PAGE_DIRTY)
@@ -207,6 +210,8 @@
 
 #define __PAGE_KERNEL \
 	(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED)
+#define __PAGE_KERNEL_WRTCOMB \
+	(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_WRTCOMB | _PAGE_ACCESSED)
 #define __PAGE_KERNEL_NOCACHE \
 	(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_PCD | _PAGE_ACCESSED)
 #define __PAGE_KERNEL_RO \
@@ -229,6 +234,7 @@
 
 #define PAGE_KERNEL MAKE_GLOBAL(__PAGE_KERNEL)
 #define PAGE_KERNEL_RO MAKE_GLOBAL(__PAGE_KERNEL_RO)
+#define PAGE_KERNEL_WRTCOMB MAKE_GLOBAL(__PAGE_KERNEL_WRTCOMB)
 #define PAGE_KERNEL_NOCACHE MAKE_GLOBAL(__PAGE_KERNEL_NOCACHE)
 
 /*
diff -ruN linux-2.4.20/init/main.c linux-2.4.20-pat/init/main.c
--- linux-2.4.20/init/main.c	2002-08-02 17:39:46.000000000 -0700
+++ linux-2.4.20-pat/init/main.c	2003-03-24 13:36:34.000000000 -0800
@@ -52,6 +52,10 @@
 #  include <asm/mtrr.h>
 #endif
 
+#ifdef CONFIG_X86_PAT
+#include <asm/pat.h>
+#endif
+
 #ifdef CONFIG_NUBUS
 #include <linux/nubus.h>
 #endif
@@ -480,6 +484,14 @@
 	mtrr_init();
 #endif
 
+#if defined(CONFIG_X86_PAT)
+    /*
+     * Initialize PAT support on all configured CPUs. This should be
+     * in an architecture specific file (x86, x86-64).
+     */
+    pat_global_setup();
+#endif
+
 #ifdef CONFIG_SYSCTL
 	sysctl_init();
 #endif

Re: pat support in the kernel

[mikpe]

Terence Ripperda <tripperda@nvidia.com>, <tripperda@nvidia.com> writes:
 > Hello all,
 > 
 > I've discussed adding Page Attribute Table (PAT) support to the kernel w/ a few developers offline. They were very supportive and suggested I bring the discussion to lkml so others could get involved.

Not that I disagre with utilising the PAT, but I don't see anything in this code to
deal with the widespread PAT indexing erratum in Intel's processors. I don't have
the errata sheets here, but it definitely affected the PIIIs and I think also some P4s.
(Large pages ignoring PAT index bit 2, or something like that.)

/Mikael

Re: pat support in the kernel

[Terence Ripperda, tripperda]

Thanks Mikael,

I was unaware of the errata, I'll check into that.

Terence

On Tue, May 20, 2003 at 09:30:35PM +0200, mikpe@csd.uu.se wrote:
> Terence Ripperda <tripperda@nvidia.com>, <tripperda@nvidia.com> writes:
>  > Hello all,
>  > 
>  > I've discussed adding Page Attribute Table (PAT) support to the kernel w/ a few developers offline. They were very supportive and suggested I bring the discussion to lkml so others could get involved.
> 
> Not that I disagre with utilising the PAT, but I don't see anything in this code to
> deal with the widespread PAT indexing erratum in Intel's processors. I don't have
> the errata sheets here, but it definitely affected the PIIIs and I think also some P4s.
> (Large pages ignoring PAT index bit 2, or something like that.)
> 
> /Mikael