mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Schlichter <thomas.schlichter@web.de>
To: "Jan Beulich" <JBeulich@novell.com>
Cc: "Jeremy Fitzhardinge" <jeremy.fitzhardinge@citrix.com>,
	"Robert Hancock" <hancockrwd@gmail.com>,
	"Henrique de Moraes Holschuh" <hmh@hmh.eng.br>,
	"Suresh Siddha" <suresh.b.siddha@intel.com>,
	"Venkatesh Pallipadi" <venkatesh.pallipadi@intel.com>,
	"Tejun Heo" <tj@kernel.org>,
	x86@kernel.org, "Yinghai Lu" <yinghai@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Arjan van de Ven" <arjan@linux.intel.com>,
	dri-devel@lists.sourceforge.net, "Ingo Molnar" <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	"Thomas Hellstrom" <thellstrom@vmware.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC Patch] use MTRR for write combining if PAT is not available
Date: Wed, 14 Oct 2009 21:14:12 +0200	[thread overview]
Message-ID: <200910142114.12433.thomas.schlichter@web.de> (raw)
In-Reply-To: <4AD5A4540200007800019CE9@vpn.id2.novell.com>

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

Jan Beulich wrote:
> >>> Thomas Schlichter <thomas.schlichter@web.de> 13.10.09 23:29 >>>
> >No, at least the comments in mtrr_add and mtrr_check state that it is just
> >required that phys_addr and size are multiple of PAGE_SIZE. And I'm not
> > sure if it is always safe to round these up/down to the next PAGE
> > boundary. If it is not, maybe it is better to fail...
> 
> That function isn't the limiting factor, generic_validate_add_page() is
> what you need to look at (plus the spec on how the MTRR ranges are
> calculated by the CPU from the base/mask register pairs).

Yes, you are right. Sorry for not looking into generic_validate_add_page() 
before. Thank you for showing!

I added a function mtrr_add_unaligned() that tries to create as many MTRR 
entries as necessary, beginning with the biggest regions. It does not check 
the return values of each mtrr_add(), nor does it return the indexes of the 
created MTRR entries. So it seems to be only useful with increment=false. Or 
do you have a better idea?

Kind regards,
  Thomas

[-- Attachment #2: 0001-Add-new-mtrr_add_unaligned-function.patch --]
[-- Type: text/x-patch, Size: 2619 bytes --]

>From 3708f0f4c729de32445ba13ab16b6268920af0bb Mon Sep 17 00:00:00 2001
From: Thomas Schlichter <thomas.schlichter@web.de>
Date: Wed, 14 Oct 2009 19:25:33 +0200
Subject: [PATCH 1/2] Add new mtrr_add_unaligned function

This function creates multiple MTRR entries for unaligned memory regions.

Signed-off-by: Thomas Schlichter <thomas.schlichter@web.de>
---
 arch/x86/include/asm/mtrr.h     |    6 ++++++
 arch/x86/kernel/cpu/mtrr/main.c |   25 +++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index 4365ffd..0ad8e68 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -116,6 +116,8 @@ extern int mtrr_add(unsigned long base, unsigned long size,
 		    unsigned int type, bool increment);
 extern int mtrr_add_page(unsigned long base, unsigned long size,
 			 unsigned int type, bool increment);
+extern void mtrr_add_unaligned(unsigned long base, unsigned long size,
+			       unsigned int type, bool increment);
 extern int mtrr_del(int reg, unsigned long base, unsigned long size);
 extern int mtrr_del_page(int reg, unsigned long base, unsigned long size);
 extern void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi);
@@ -146,6 +148,10 @@ static inline int mtrr_add_page(unsigned long base, unsigned long size,
 {
     return -ENODEV;
 }
+static inline void mtrr_add_unaligned(unsigned long base, unsigned long size,
+				      unsigned int type, bool increment)
+{
+}
 static inline int mtrr_del(int reg, unsigned long base, unsigned long size)
 {
     return -ENODEV;
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 84e83de..7417ebb 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -487,6 +487,31 @@ int mtrr_add(unsigned long base, unsigned long size, unsigned int type,
 }
 EXPORT_SYMBOL(mtrr_add);
 
+void mtrr_add_unaligned(unsigned long base, unsigned long size,
+			unsigned int type, bool increment)
+{
+	unsigned long ptr1, ptr2, end = base + size;
+
+	// round down size to next power ot two
+	size = __rounddown_pow_of_two(size);
+
+	// accordingly align pointers
+	ptr1 = ptr2 = (base + size - 1) & ~(size - 1);
+
+	while (size >= PAGE_SIZE) {
+		if (ptr1 + size <= end) {
+			mtrr_add(ptr1, size, type, increment);
+			ptr1 += size;
+		}
+		if (base + size <= ptr2) {
+			ptr2 -= size;
+			mtrr_add(ptr2, size, type, increment);
+		}
+		size >>= 1;
+	}
+}
+EXPORT_SYMBOL(mtrr_add_unaligned);
+
 /**
  * mtrr_del_page - delete a memory type region
  * @reg: Register returned by mtrr_add
-- 
1.6.5


[-- Attachment #3: 0002-Use-MTRR-for-write-combining-mmap-ioremap-if-PAT-is-.patch --]
[-- Type: text/x-patch, Size: 3275 bytes --]

>From 3533b9e66c5144844a0b0864d0f57f43d57aea1a Mon Sep 17 00:00:00 2001
From: Thomas Schlichter <thomas.schlichter@web.de>
Date: Thu, 8 Oct 2009 21:24:07 +0200
Subject: [PATCH 2/2] Use MTRR for write combining mmap/ioremap if PAT is not available

X.org uses libpciaccess which tries to mmap with write combining enabled via
/sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, we
fall back to uncached mmap. Then libpciaccess thinks it succeeded mapping
with write combining anabled and does not set up suited MTRR entries. ;-(

So when falling back to uncached mapping, we better try to set up MTRR
entries automatically. To match this modified PCI mmap behavior, also
ioremap_wc and set_memory_wc are adjusted.

Signed-off-by: Thomas Schlichter <thomas.schlichter@web.de>
---
 arch/x86/mm/ioremap.c  |   15 ++++++++++-----
 arch/x86/mm/pageattr.c |   10 ++++++++--
 arch/x86/pci/i386.c    |    6 ++++++
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 334e63c..abe40fa 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -21,6 +21,7 @@
 #include <asm/tlbflush.h>
 #include <asm/pgalloc.h>
 #include <asm/pat.h>
+#include <asm/mtrr.h>
 
 #include "physaddr.h"
 
@@ -268,11 +269,15 @@ EXPORT_SYMBOL(ioremap_nocache);
  */
 void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
 {
-	if (pat_enabled)
-		return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WC,
-					__builtin_return_address(0));
-	else
-		return ioremap_nocache(phys_addr, size);
+	if (!pat_enabled) {
+		void __iomem *ret = ioremap_nocache(phys_addr, size);
+		if (ret)
+			mtrr_add_unaligned(phys_addr, size,
+					   MTRR_TYPE_WRCOMB, false);
+		return ret;
+	}
+	return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WC,
+				__builtin_return_address(0));
 }
 EXPORT_SYMBOL(ioremap_wc);
 
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index dd38bfb..c25f697 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -23,6 +23,7 @@
 #include <asm/pgalloc.h>
 #include <asm/proto.h>
 #include <asm/pat.h>
+#include <asm/mtrr.h>
 
 /*
  * The current flushing context - we pass it instead of 5 arguments:
@@ -1010,8 +1011,13 @@ int set_memory_wc(unsigned long addr, int numpages)
 {
 	int ret;
 
-	if (!pat_enabled)
-		return set_memory_uc(addr, numpages);
+	if (!pat_enabled) {
+		ret = set_memory_uc(addr, numpages);
+		if (!ret)
+			mtrr_add_unaligned(__pa(addr), numpages * PAGE_SIZE,
+					   MTRR_TYPE_WRCOMB, false);
+		return ret;
+	}
 
 	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
 		_PAGE_CACHE_WC, NULL);
diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index b22d13b..8379e9b 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -33,6 +33,7 @@
 #include <linux/bootmem.h>
 
 #include <asm/pat.h>
+#include <asm/mtrr.h>
 #include <asm/e820.h>
 #include <asm/pci_x86.h>
 #include <asm/io_apic.h>
@@ -301,5 +302,10 @@ int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
 
 	vma->vm_ops = &pci_mmap_ops;
 
+	if (!pat_enabled && write_combine)
+		mtrr_add_unaligned(vma->vm_pgoff << PAGE_SHIFT,
+				   vma->vm_end - vma->vm_start,
+				   MTRR_TYPE_WRCOMB, false);
+
 	return 0;
 }
-- 
1.6.5


  reply	other threads:[~2009-10-14 19:14 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-13  7:34 Jan Beulich
2009-10-13 21:29 ` Thomas Schlichter
2009-10-14  8:13   ` Jan Beulich
2009-10-14 19:14     ` Thomas Schlichter [this message]
2009-10-15  7:48       ` Jan Beulich
2009-10-17 19:48         ` Thomas Schlichter
2009-10-19  9:16           ` Jan Beulich
2009-10-19 13:44             ` Suresh Siddha
2009-10-19 13:54               ` Ingo Molnar
2009-10-19 13:36           ` Konrad Rzeszutek Wilk
  -- strict thread matches above, loose matches on Subject: below --
2009-10-22 14:41 Thomas Schlichter
2009-10-22 14:27 Thomas Schlichter
2009-10-22 12:08 Thomas Schlichter
2009-10-22 12:14 ` H. Peter Anvin
2009-10-22 13:26   ` Suresh Siddha
2009-10-22 13:35 ` Suresh Siddha
2009-10-21 14:38 Thomas Schlichter
2009-10-21 15:14 ` Jan Beulich
2009-10-21 13:45 Thomas Schlichter
2009-10-21 14:11 ` Jan Beulich
2009-10-21 17:35   ` Ingo Molnar
2009-10-21 20:01     ` Thomas Schlichter
2009-10-22  9:53       ` Suresh Siddha
2009-10-22 15:34         ` Eric Anholt
2009-10-22 21:47           ` Suresh Siddha
2009-10-22 23:10             ` Jesse Barnes
2009-10-23  0:11               ` Suresh Siddha
2009-10-23  1:53                 ` Eric Anholt
2009-10-23  4:31                   ` Jesse Barnes
2009-10-23  4:58                     ` Suresh Siddha
2009-10-23  7:24                       ` Thomas Schlichter
2009-10-23 14:24                         ` Suresh Siddha
2009-10-23 14:37                           ` Ingo Molnar
2009-10-23  4:33                   ` Suresh Siddha
2009-10-19 15:10 Thomas Schlichter
2009-10-19 15:28 ` Ingo Molnar
2009-10-19 15:07 Thomas Schlichter
2009-10-19 14:59 Thomas Schlichter
2009-10-19 15:31 ` Ingo Molnar
2009-10-19 21:49   ` Suresh Siddha
2009-10-20 20:35   ` Thomas Schlichter
2009-10-20 21:59     ` Suresh Siddha
2009-10-21 11:52       ` Ingo Molnar
2009-10-19 14:47 Thomas Schlichter
2009-10-20 19:54 ` Thomas Schlichter
2009-10-21 11:57   ` Ingo Molnar
     [not found] <200910122032.52168.thomas.schlichter@web.de>
2009-10-12 19:16 ` Thomas Hellstrom
2009-10-12 19:45   ` Thomas Schlichter
     [not found]     ` <1255378684.2063.5.camel@gaiman.anholt.net>
2009-10-13 21:05       ` Thomas Schlichter
2009-10-10  1:22 Thomas Schlichter
2009-10-10  4:24 ` Arjan van de Ven
2009-10-10  8:31   ` Thomas Schlichter
2009-10-10 15:45     ` Arjan van de Ven
2009-10-10 17:50       ` Roland Dreier
2009-10-11  7:40       ` Ingo Molnar
2009-10-11  9:56       ` Thomas Schlichter
2009-10-11 18:51   ` Henrique de Moraes Holschuh
2009-10-11 18:54     ` Arjan van de Ven
2009-10-11 20:19       ` Henrique de Moraes Holschuh
2009-10-12 18:09         ` Robert Hancock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200910142114.12433.thomas.schlichter@web.de \
    --to=thomas.schlichter@web.de \
    --cc=JBeulich@novell.com \
    --cc=arjan@linux.intel.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=hancockrwd@gmail.com \
    --cc=hmh@hmh.eng.br \
    --cc=hpa@zytor.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=thellstrom@vmware.com \
    --cc=tj@kernel.org \
    --cc=venkatesh.pallipadi@intel.com \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome