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
next prev parent 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