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: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` [RFC PATCH 2/11] x86, mm, pat: Define _PAGE_CACHE_WT for PA3/7 of PAT 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:56 ` Andy Lutomirski
2014-07-15 23:10 ` Toshi Kani
2014-07-15 23:36 ` Andy Lutomirski
2014-07-15 23:46 ` H. Peter Anvin
2014-07-15 23:54 ` Andy Lutomirski
2014-07-15 23:59 ` H. Peter Anvin
2014-07-15 23:53 ` Toshi Kani
2014-07-16 0:05 ` H. Peter Anvin
2014-07-16 0:28 ` Andy Lutomirski
2014-07-16 0:31 ` H. Peter Anvin
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 ` [RFC PATCH 5/11] x86, mm: Add set_memory[_array]_wt() for setting WT 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 ` [RFC PATCH 7/11] x86, mm: Keep _set_memory_<type>() slot-independent 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 ` [RFC PATCH 9/11] x86, efi: Cleanup PCD bit manipulation in EFI 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 ` [RFC PATCH 11/11] x86, fbdev: Cleanup PWT/PCD bit manipulation in fbdev Toshi Kani
2014-07-15 19:53 ` [RFC PATCH 0/11] Support Write-Through mapping on x86 Andy Lutomirski
2014-07-15 20:10 ` H. Peter Anvin
2014-07-15 20:09 ` H. Peter Anvin
2014-07-15 21:23 ` Toshi Kani
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 17:16 ` Toshi Kani
2014-07-21 17:32 ` H. Peter Anvin
2014-07-21 17:33 ` Toshi Kani
2014-07-21 18:33 ` Konrad Rzeszutek Wilk
2014-07-21 19:24 ` Toshi Kani
2014-07-21 20:22 ` H. Peter Anvin
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox