From: Toshi Kani <toshi.kani@hp.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
tglx@linutronix.de, mingo@redhat.com, akpm@linux-foundation.org,
arnd@arndb.de, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
stefan.bader@canonical.com, luto@amacapital.net,
airlied@gmail.com, bp@alien8.de
Subject: Re: [RFC PATCH 0/11] Support Write-Through mapping on x86
Date: Wed, 16 Jul 2014 15:28:47 -0600 [thread overview]
Message-ID: <1405546127.28702.85.camel@misato.fc.hp.com> (raw)
In-Reply-To: <03d059f5-b564-4530-9184-f91ca9d5c016@email.android.com>
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
On Tue, 2014-07-15 at 20:40 -0400, Konrad Rzeszutek Wilk wrote:
> On July 15, 2014 5:23:24 PM EDT, Toshi Kani <toshi.kani@hp.com> wrote:
> >On Tue, 2014-07-15 at 13:09 -0700, H. Peter Anvin wrote:
> >> On 07/15/2014 12:34 PM, Toshi Kani wrote:
:
> >>
> >> I have given this piece of feedback at least three times now,
> >possibly
> >> to different people, and I'm getting a bit grumpy about it:
> >>
> >> We already have an issue with Xen, because Xen assigned mappings
> >> differently and it is incompatible with the use of PAT in Linux. As
> >a
> >> result we get requests for hacks to work around this, which is
> >something
> >> I really don't want to see. I would like to see a design involving a
> >> "reverse PAT" table where the kernel can hold the mapping between
> >memory
> >> types and page table encodings (including the two different ones for
> >> small and large pages.)
> >
> >Thanks for pointing this out! (And sorry for making you repeat it three
> >time...) I was not aware of the issue with Xen. I will look into the
> >email archive to see what the Xen issue is, and how it can be
> >addressed.
>
> https://lkml.org/lkml/2011/11/8/406
Thanks Konrad for the pointer!
Since [__]change_page_attr_set_clr() and __change_page_attr() have no
knowledge about PAT and simply work with specified PTE flags, they do
not seem to fit well with additional PAT abstraction table...
I think the root of this issue is that the kernel ignores the PAT bit.
Since __change_page_attr() only supports 4K pages, set_memory_<type>()
can set the PAT bit into the clear mask.
Attached is a patch with this approach (apply on top of this series -
not tested). The kernel still does not support the PAT bit, but it
behaves slightly better.
Thanks,
-Toshi
[-- Attachment #2: page-ext-mask.patch --]
[-- Type: text/x-patch, Size: 3716 bytes --]
From: Toshi Kani <toshi.kani@hp.com>
---
arch/x86/include/asm/pgtable_types.h | 1 +
arch/x86/mm/pageattr.c | 20 ++++++++++----------
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 81a3859..a392b09 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -130,6 +130,7 @@
#define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE | _PAGE_NUMA)
#define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT)
+#define _PAGE_CACHE_EXT_MASK (_PAGE_CACHE_MASK | _PAGE_PAT)
#define _PAGE_CACHE_WB (0)
#define _PAGE_CACHE_WC (_PAGE_PWT)
#define _PAGE_CACHE_WT (_PAGE_PCD | _PAGE_PWT)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index da597d0..348f206 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1446,7 +1446,7 @@ int _set_memory_uc(unsigned long addr, int numpages)
*/
return change_page_attr_set_clr(&addr, numpages,
__pgprot(_PAGE_CACHE_UC_MINUS),
- __pgprot(_PAGE_CACHE_MASK),
+ __pgprot(_PAGE_CACHE_EXT_MASK),
0, 0, NULL);
}
@@ -1493,13 +1493,13 @@ static int _set_memory_array(unsigned long *addr, int addrinarray,
ret = change_page_attr_set_clr(addr, addrinarray,
__pgprot(_PAGE_CACHE_UC_MINUS),
- __pgprot(_PAGE_CACHE_MASK),
+ __pgprot(_PAGE_CACHE_EXT_MASK),
0, CPA_ARRAY, NULL);
if (!ret && new_type == _PAGE_CACHE_WC)
ret = change_page_attr_set_clr(addr, addrinarray,
__pgprot(_PAGE_CACHE_WC),
- __pgprot(_PAGE_CACHE_MASK),
+ __pgprot(_PAGE_CACHE_EXT_MASK),
0, CPA_ARRAY, NULL);
if (ret)
goto out_free;
@@ -1532,12 +1532,12 @@ int _set_memory_wc(unsigned long addr, int numpages)
ret = change_page_attr_set_clr(&addr, numpages,
__pgprot(_PAGE_CACHE_UC_MINUS),
- __pgprot(_PAGE_CACHE_MASK),
+ __pgprot(_PAGE_CACHE_EXT_MASK),
0, 0, NULL);
if (!ret) {
ret = change_page_attr_set_clr(&addr_copy, numpages,
__pgprot(_PAGE_CACHE_WC),
- __pgprot(_PAGE_CACHE_MASK),
+ __pgprot(_PAGE_CACHE_EXT_MASK),
0, 0, NULL);
}
return ret;
@@ -1578,7 +1578,7 @@ int _set_memory_wt(unsigned long addr, int numpages)
{
return change_page_attr_set_clr(&addr, numpages,
__pgprot(_PAGE_CACHE_WT),
- __pgprot(_PAGE_CACHE_MASK),
+ __pgprot(_PAGE_CACHE_EXT_MASK),
0, 0, NULL);
}
@@ -1611,7 +1611,7 @@ int _set_memory_wb(unsigned long addr, int numpages)
{
return change_page_attr_set_clr(&addr, numpages,
__pgprot(_PAGE_CACHE_WB),
- __pgprot(_PAGE_CACHE_MASK),
+ __pgprot(_PAGE_CACHE_EXT_MASK),
0, 0, NULL);
}
@@ -1635,7 +1635,7 @@ int set_memory_array_wb(unsigned long *addr, int addrinarray)
ret = change_page_attr_set_clr(addr, addrinarray,
__pgprot(_PAGE_CACHE_WB),
- __pgprot(_PAGE_CACHE_MASK),
+ __pgprot(_PAGE_CACHE_EXT_MASK),
0, CPA_ARRAY, NULL);
if (ret)
return ret;
@@ -1719,7 +1719,7 @@ static int _set_pages_array(struct page **pages, int addrinarray,
if (!ret && new_type == _PAGE_CACHE_WC)
ret = change_page_attr_set_clr(NULL, addrinarray,
__pgprot(_PAGE_CACHE_WC),
- __pgprot(_PAGE_CACHE_MASK),
+ __pgprot(_PAGE_CACHE_EXT_MASK),
0, CPA_PAGES_ARRAY, pages);
if (ret)
goto err_out;
@@ -1770,7 +1770,7 @@ int set_pages_array_wb(struct page **pages, int addrinarray)
int i;
retval = cpa_clear_pages_array(pages, addrinarray,
- __pgprot(_PAGE_CACHE_MASK));
+ __pgprot(_PAGE_CACHE_EXT_MASK));
if (retval)
return retval;
next prev parent reply other threads:[~2014-07-16 21:38 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 19:34 [RFC PATCH 0/11] Support Write-Through mapping on x86 Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 1/11] x86, mm, pat: Redefine _PAGE_CACHE_UC as UC_MINUS Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 2/11] x86, mm, pat: Define _PAGE_CACHE_WT for PA3/7 of PAT Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 3/11] x86, mm, pat: Change reserve_memtype() to handle WT type Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:56 ` Andy Lutomirski
2014-07-15 19:56 ` Andy Lutomirski
2014-07-15 23:10 ` Toshi Kani
2014-07-15 23:10 ` Toshi Kani
2014-07-15 23:36 ` Andy Lutomirski
2014-07-15 23:36 ` Andy Lutomirski
2014-07-15 23:46 ` H. Peter Anvin
2014-07-15 23:46 ` H. Peter Anvin
2014-07-15 23:54 ` Andy Lutomirski
2014-07-15 23:54 ` Andy Lutomirski
2014-07-15 23:59 ` H. Peter Anvin
2014-07-15 23:59 ` H. Peter Anvin
2014-07-15 23:53 ` Toshi Kani
2014-07-15 23:53 ` Toshi Kani
2014-07-16 0:05 ` H. Peter Anvin
2014-07-16 0:05 ` H. Peter Anvin
2014-07-16 0:28 ` Andy Lutomirski
2014-07-16 0:28 ` Andy Lutomirski
2014-07-16 0:31 ` H. Peter Anvin
2014-07-16 0:31 ` H. Peter Anvin
2014-07-16 14:35 ` Toshi Kani
2014-07-16 14:35 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 4/11] x86, mm, asm-gen: Add ioremap_wt() for WT mapping Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 5/11] x86, mm: Add set_memory[_array]_wt() for setting WT Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 6/11] x86, mm, pat: Add pgprot_writethrough() for WT Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 7/11] x86, mm: Keep _set_memory_<type>() slot-independent Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 8/11] x86, mm, pat: Keep pgprot_<type>() slot-independent Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 9/11] x86, efi: Cleanup PCD bit manipulation in EFI Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 10/11] x86, xen: Cleanup PWT/PCD bit manipulation in Xen Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 11/11] x86, fbdev: Cleanup PWT/PCD bit manipulation in fbdev Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:53 ` [RFC PATCH 0/11] Support Write-Through mapping on x86 Andy Lutomirski
2014-07-15 19:53 ` Andy Lutomirski
2014-07-15 20:10 ` H. Peter Anvin
2014-07-15 20:10 ` H. Peter Anvin
2014-07-15 20:09 ` H. Peter Anvin
2014-07-15 20:09 ` H. Peter Anvin
2014-07-15 21:23 ` Toshi Kani
2014-07-15 21:23 ` Toshi Kani
2014-07-16 0:40 ` Konrad Rzeszutek Wilk
2014-07-16 0:40 ` Konrad Rzeszutek Wilk
2014-07-16 21:28 ` Toshi Kani [this message]
2014-07-21 16:31 ` Toshi Kani
2014-07-21 16:47 ` H. Peter Anvin
2014-07-21 16:47 ` H. Peter Anvin
2014-07-21 17:16 ` Toshi Kani
2014-07-21 17:16 ` Toshi Kani
2014-07-21 17:32 ` H. Peter Anvin
2014-07-21 17:32 ` H. Peter Anvin
2014-07-21 17:33 ` Toshi Kani
2014-07-21 17:33 ` Toshi Kani
2014-07-21 18:33 ` Konrad Rzeszutek Wilk
2014-07-21 18:33 ` Konrad Rzeszutek Wilk
2014-07-21 19:24 ` Toshi Kani
2014-07-21 19:24 ` Toshi Kani
2014-07-21 20:22 ` H. Peter Anvin
2014-07-21 20:22 ` H. Peter Anvin
2014-07-21 17:20 ` Toshi Kani
2014-07-21 17:20 ` Toshi Kani
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=1405546127.28702.85.camel@misato.fc.hp.com \
--to=toshi.kani@hp.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=plagnioj@jcrosoft.com \
--cc=stefan.bader@canonical.com \
--cc=tglx@linutronix.de \
--cc=tomi.valkeinen@ti.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.