From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by kanga.kvack.org (Postfix) with ESMTP id 16CDF6B0036 for ; Thu, 4 Sep 2014 14:46:09 -0400 (EDT) Received: by mail-yk0-f169.google.com with SMTP id q200so6412036ykb.0 for ; Thu, 04 Sep 2014 11:46:08 -0700 (PDT) Received: from g5t1625.atlanta.hp.com (g5t1625.atlanta.hp.com. [15.192.137.8]) by mx.google.com with ESMTPS id q40si13615508yhg.97.2014.09.04.11.46.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 11:46:08 -0700 (PDT) From: Toshi Kani Subject: [PATCH 0/5] Support Write-Through mapping on x86 Date: Thu, 4 Sep 2014 12:35:34 -0600 Message-Id: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: owner-linux-mm@kvack.org List-ID: To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com This patchset adds support of Write-Through (WT) mapping on x86. The study below shows that using WT mapping may be useful for non-volatile memory. http://www.hpl.hp.com/techreports/2012/HPL-2012-236.pdf This patchset applies on top of the Juergen's patchset below, which provides the basis of the PAT management. https://lkml.org/lkml/2014/8/26/61 All new/modified interfaces have been tested. --- Toshi Kani (5): 1/5 x86, mm, pat: Set WT to PA4 slot of PAT MSR 2/5 x86, mm, pat: Change reserve_memtype() to handle WT 3/5 x86, mm, asm-gen: Add ioremap_wt() for WT 4/5 x86, mm: Add set_memory_wt() for WT 5/5 x86, mm, pat: Add pgprot_writethrough() for WT --- arch/x86/include/asm/cacheflush.h | 10 ++++- arch/x86/include/asm/io.h | 2 + arch/x86/include/asm/pgtable_types.h | 3 ++ arch/x86/mm/ioremap.c | 24 ++++++++++++ arch/x86/mm/pageattr.c | 73 +++++++++++++++++++++++++++++++++--- arch/x86/mm/pat.c | 73 +++++++++++++++++++++++++++--------- include/asm-generic/io.h | 4 ++ include/asm-generic/iomap.h | 4 ++ include/asm-generic/pgtable.h | 4 ++ 9 files changed, 172 insertions(+), 25 deletions(-) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f49.google.com (mail-yh0-f49.google.com [209.85.213.49]) by kanga.kvack.org (Postfix) with ESMTP id 3DAA26B0036 for ; Thu, 4 Sep 2014 14:47:29 -0400 (EDT) Received: by mail-yh0-f49.google.com with SMTP id z6so6639168yhz.8 for ; Thu, 04 Sep 2014 11:47:29 -0700 (PDT) Received: from g5t1626.atlanta.hp.com (g5t1626.atlanta.hp.com. [15.192.137.9]) by mx.google.com with ESMTPS id a7si13617016yhd.106.2014.09.04.11.47.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 11:47:28 -0700 (PDT) From: Toshi Kani Subject: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Date: Thu, 4 Sep 2014 12:35:35 -0600 Message-Id: <1409855739-8985-2-git-send-email-toshi.kani@hp.com> In-Reply-To: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: owner-linux-mm@kvack.org List-ID: To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com, Toshi Kani This patch sets WT to the PA4 slot in the PAT MSR when the processor is not affected by the PAT errata. The upper 4 slots of the PAT MSR are continued to be unused on the following Intel processors. errata cpuid -------------------------------------- Pentium 2, A52 family 0x6, model 0x5 Pentium 3, E27 family 0x6, model 0x7 Pentium M, Y26 family 0x6, model 0x9 Pentium 4, N46 family 0xf, model 0x0 For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- per the default setup in __cachemode2pte_tbl[]. Signed-off-by: Toshi Kani --- arch/x86/mm/pat.c | 47 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 15 deletions(-) diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c index feb4d30..b1891dc 100644 --- a/arch/x86/mm/pat.c +++ b/arch/x86/mm/pat.c @@ -132,6 +132,7 @@ void pat_init(void) { u64 pat; bool boot_cpu = !boot_pat_state; + struct cpuinfo_x86 *c = &boot_cpu_data; if (!pat_enabled) return; @@ -152,21 +153,37 @@ void pat_init(void) } } - /* Set PWT to Write-Combining. All other bits stay the same */ - /* - * PTE encoding used in Linux: - * PAT - * |PCD - * ||PWT - * ||| - * 000 WB _PAGE_CACHE_WB - * 001 WC _PAGE_CACHE_WC - * 010 UC- _PAGE_CACHE_UC_MINUS - * 011 UC _PAGE_CACHE_UC - * PAT bit unused - */ - pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) | - PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC); + if ((c->x86_vendor == X86_VENDOR_INTEL) && + (((c->x86 == 0x6) && + ((c->x86_model == 0x5) || + (c->x86_model == 0x7) || + (c->x86_model == 0x9))) || + ((c->x86 == 0xf) && (c->x86_model == 0x0)))) { + /* + * Upper four PAT entries are not usable on the following + * Intel processors. + * + * errata cpuid + * -------------------------------------- + * Pentium 2, A52 family 0x6, model 0x5 + * Pentium 3, E27 family 0x6, model 0x7 + * Pentium M, Y26 family 0x6, model 0x9 + * Pentium 4, N46 family 0xf, model 0x0 + * + * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-7:unusable + * + * NOTE: When WT or WP is used, it is redirected * to UC- + * per the default setup in __cachemode2pte_tbl[]. + */ + pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) | + PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC); + } else { + /* + * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4:WT, 5-7:reserved + */ + pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) | + PAT(4, WT) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC); + } /* Boot CPU check */ if (!boot_pat_state) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) by kanga.kvack.org (Postfix) with ESMTP id A9E886B0037 for ; Thu, 4 Sep 2014 14:47:34 -0400 (EDT) Received: by mail-yk0-f176.google.com with SMTP id 19so6209499ykq.7 for ; Thu, 04 Sep 2014 11:47:34 -0700 (PDT) Received: from g6t1525.atlanta.hp.com (g6t1525.atlanta.hp.com. [15.193.200.68]) by mx.google.com with ESMTPS id i1si13577413yhg.148.2014.09.04.11.47.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 11:47:34 -0700 (PDT) From: Toshi Kani Subject: [PATCH 2/5] x86, mm, pat: Change reserve_memtype() to handle WT Date: Thu, 4 Sep 2014 12:35:36 -0600 Message-Id: <1409855739-8985-3-git-send-email-toshi.kani@hp.com> In-Reply-To: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: owner-linux-mm@kvack.org List-ID: To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com, Toshi Kani This patch changes reserve_memtype() to handle the WT cache mode. When PAT is not enabled, it continues to set UC- to *new_type for any non-WB request. When a target range is RAM, reserve_ram_pages_type() fails for WT for now. This function may not reserve a RAM range for WT since reserve_ram_pages_type() uses the page flags limited to three memory types, WB, WC and UC. Signed-off-by: Toshi Kani --- arch/x86/include/asm/cacheflush.h | 4 ++++ arch/x86/mm/pat.c | 16 +++++++++++++--- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h index 157644b..c912680 100644 --- a/arch/x86/include/asm/cacheflush.h +++ b/arch/x86/include/asm/cacheflush.h @@ -53,6 +53,10 @@ static inline void set_page_memtype(struct page *pg, case _PAGE_CACHE_MODE_WB: memtype_flags = _PGMT_WB; break; + case _PAGE_CACHE_MODE_WT: + case _PAGE_CACHE_MODE_WP: + pr_err("set_page_memtype: unsupported cachemode %d\n", memtype); + BUG(); default: memtype_flags = _PGMT_DEFAULT; break; diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c index b1891dc..87b21dd 100644 --- a/arch/x86/mm/pat.c +++ b/arch/x86/mm/pat.c @@ -271,6 +271,8 @@ static int pat_pagerange_is_ram(resource_size_t start, resource_size_t end) /* * For RAM pages, we use page flags to mark the pages with appropriate type. + * The page flags are currently limited to three types, WB, WC and UC. Hence, + * any request to WT or WP will fail with -EINVAL. * Here we do two pass: * - Find the memtype of all the pages in the range, look for any conflicts * - In case of no conflicts, set the new memtype for pages in the range @@ -282,6 +284,13 @@ static int reserve_ram_pages_type(u64 start, u64 end, struct page *page; u64 pfn; + if ((req_type == _PAGE_CACHE_MODE_WT) || + (req_type == _PAGE_CACHE_MODE_WP)) { + if (new_type) + *new_type = _PAGE_CACHE_MODE_UC_MINUS; + return -EINVAL; + } + if (req_type == _PAGE_CACHE_MODE_UC) { /* We do not support strong UC */ WARN_ON_ONCE(1); @@ -331,6 +340,7 @@ static int free_ram_pages_type(u64 start, u64 end) * - _PAGE_CACHE_MODE_WC * - _PAGE_CACHE_MODE_UC_MINUS * - _PAGE_CACHE_MODE_UC + * - _PAGE_CACHE_MODE_WT * * If new_type is NULL, function will return an error if it cannot reserve the * region with req_type. If new_type is non-NULL, function will return @@ -350,10 +360,10 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type, if (!pat_enabled) { /* This is identical to page table setting without PAT */ if (new_type) { - if (req_type == _PAGE_CACHE_MODE_WC) - *new_type = _PAGE_CACHE_MODE_UC_MINUS; + if (req_type == _PAGE_CACHE_MODE_WB) + *new_type = _PAGE_CACHE_MODE_WB; else - *new_type = req_type; + *new_type = _PAGE_CACHE_MODE_UC_MINUS; } return 0; } -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by kanga.kvack.org (Postfix) with ESMTP id E16836B0038 for ; Thu, 4 Sep 2014 14:47:37 -0400 (EDT) Received: by mail-yh0-f54.google.com with SMTP id b6so6673752yha.13 for ; Thu, 04 Sep 2014 11:47:37 -0700 (PDT) Received: from g5t1625.atlanta.hp.com (g5t1625.atlanta.hp.com. [15.192.137.8]) by mx.google.com with ESMTPS id y49si8697147yhc.54.2014.09.04.11.47.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 11:47:37 -0700 (PDT) From: Toshi Kani Subject: [PATCH 3/5] x86, mm, asm-gen: Add ioremap_wt() for WT Date: Thu, 4 Sep 2014 12:35:37 -0600 Message-Id: <1409855739-8985-4-git-send-email-toshi.kani@hp.com> In-Reply-To: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: owner-linux-mm@kvack.org List-ID: To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com, Toshi Kani This patch adds ioremap_wt() for creating WT mapping on x86. It follows the same model as ioremap_wc() for multi-architecture support. ARCH_HAS_IOREMAP_WT is defined in the x86 version of io.h to indicate that ioremap_wt() is implemented on x86. Signed-off-by: Toshi Kani --- arch/x86/include/asm/io.h | 2 ++ arch/x86/mm/ioremap.c | 24 ++++++++++++++++++++++++ include/asm-generic/io.h | 4 ++++ include/asm-generic/iomap.h | 4 ++++ 4 files changed, 34 insertions(+) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 71b9e65..c813c86 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -35,6 +35,7 @@ */ #define ARCH_HAS_IOREMAP_WC +#define ARCH_HAS_IOREMAP_WT #include #include @@ -316,6 +317,7 @@ extern void unxlate_dev_mem_ptr(unsigned long phys, void *addr); extern int ioremap_change_attr(unsigned long vaddr, unsigned long size, enum page_cache_mode pcm); extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size); +extern void __iomem *ioremap_wt(resource_size_t offset, unsigned long size); extern bool is_early_ioremap_ptep(pte_t *ptep); diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 885fe44..952f4b4 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -155,6 +155,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr, prot = __pgprot(pgprot_val(prot) | cachemode2protval(_PAGE_CACHE_MODE_WC)); break; + case _PAGE_CACHE_MODE_WT: + prot = __pgprot(pgprot_val(prot) | + cachemode2protval(_PAGE_CACHE_MODE_WT)); + break; case _PAGE_CACHE_MODE_WB: break; } @@ -249,6 +253,26 @@ void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size) } EXPORT_SYMBOL(ioremap_wc); +/** + * ioremap_wt - map memory into CPU space write through + * @phys_addr: bus address of the memory + * @size: size of the resource to map + * + * This version of ioremap ensures that the memory is marked write through. + * Write through writes data into memory while keeping the cache up-to-date. + * + * Must be freed with iounmap. + */ +void __iomem *ioremap_wt(resource_size_t phys_addr, unsigned long size) +{ + if (pat_enabled) + return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WT, + __builtin_return_address(0)); + else + return ioremap_nocache(phys_addr, size); +} +EXPORT_SYMBOL(ioremap_wt); + void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size) { return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB, diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index 975e1cc..405d418 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -322,6 +322,10 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) #define ioremap_wc ioremap_nocache #endif +#ifndef ioremap_wt +#define ioremap_wt ioremap_nocache +#endif + static inline void iounmap(void __iomem *addr) { } diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h index 1b41011..d8f8622 100644 --- a/include/asm-generic/iomap.h +++ b/include/asm-generic/iomap.h @@ -66,6 +66,10 @@ extern void ioport_unmap(void __iomem *); #define ioremap_wc ioremap_nocache #endif +#ifndef ARCH_HAS_IOREMAP_WT +#define ioremap_wt ioremap_nocache +#endif + #ifdef CONFIG_PCI /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev; -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f181.google.com (mail-yk0-f181.google.com [209.85.160.181]) by kanga.kvack.org (Postfix) with ESMTP id 9ED816B0039 for ; Thu, 4 Sep 2014 14:47:40 -0400 (EDT) Received: by mail-yk0-f181.google.com with SMTP id 131so6290850ykp.40 for ; Thu, 04 Sep 2014 11:47:40 -0700 (PDT) Received: from g6t1526.atlanta.hp.com (g6t1526.atlanta.hp.com. [15.193.200.69]) by mx.google.com with ESMTPS id r42si13548743yho.178.2014.09.04.11.47.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 11:47:40 -0700 (PDT) From: Toshi Kani Subject: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT Date: Thu, 4 Sep 2014 12:35:38 -0600 Message-Id: <1409855739-8985-5-git-send-email-toshi.kani@hp.com> In-Reply-To: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: owner-linux-mm@kvack.org List-ID: To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com, Toshi Kani This patch adds set_memory_wt(), set_memory_array_wt(), and set_pages_array_wt() for setting range(s) of memory to WT. Note that reserve_memtype() only supports WT for non-RAM ranges at this point. Signed-off-by: Toshi Kani --- arch/x86/include/asm/cacheflush.h | 6 +++ arch/x86/mm/pageattr.c | 73 ++++++++++++++++++++++++++++++++++--- 2 files changed, 72 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h index c912680..5bfd5d0 100644 --- a/arch/x86/include/asm/cacheflush.h +++ b/arch/x86/include/asm/cacheflush.h @@ -81,7 +81,7 @@ static inline void set_page_memtype(struct page *pg, /* * The set_memory_* API can be used to change various attributes of a virtual * address range. The attributes include: - * Cachability : UnCached, WriteCombining, WriteBack + * Cachability : UnCached, WriteCombining, WriteThrough, WriteBack * Executability : eXeutable, NoteXecutable * Read/Write : ReadOnly, ReadWrite * Presence : NotPresent @@ -108,9 +108,11 @@ static inline void set_page_memtype(struct page *pg, int _set_memory_uc(unsigned long addr, int numpages); int _set_memory_wc(unsigned long addr, int numpages); +int _set_memory_wt(unsigned long addr, int numpages); int _set_memory_wb(unsigned long addr, int numpages); int set_memory_uc(unsigned long addr, int numpages); int set_memory_wc(unsigned long addr, int numpages); +int set_memory_wt(unsigned long addr, int numpages); int set_memory_wb(unsigned long addr, int numpages); int set_memory_x(unsigned long addr, int numpages); int set_memory_nx(unsigned long addr, int numpages); @@ -121,10 +123,12 @@ int set_memory_4k(unsigned long addr, int numpages); int set_memory_array_uc(unsigned long *addr, int addrinarray); int set_memory_array_wc(unsigned long *addr, int addrinarray); +int set_memory_array_wt(unsigned long *addr, int addrinarray); int set_memory_array_wb(unsigned long *addr, int addrinarray); int set_pages_array_uc(struct page **pages, int addrinarray); int set_pages_array_wc(struct page **pages, int addrinarray); +int set_pages_array_wt(struct page **pages, int addrinarray); int set_pages_array_wb(struct page **pages, int addrinarray); /* diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 6917b39..2dda151 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -1484,12 +1484,10 @@ EXPORT_SYMBOL(set_memory_uc); static int _set_memory_array(unsigned long *addr, int addrinarray, enum page_cache_mode new_type) { + enum page_cache_mode set_type; int i, j; int ret; - /* - * for now UC MINUS. see comments in ioremap_nocache() - */ for (i = 0; i < addrinarray; i++) { ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE, new_type, NULL); @@ -1497,9 +1495,12 @@ static int _set_memory_array(unsigned long *addr, int addrinarray, goto out_free; } + /* If WC, set to UC- first and then WC */ + set_type = (new_type == _PAGE_CACHE_MODE_WC) ? + _PAGE_CACHE_MODE_UC_MINUS : new_type; + ret = change_page_attr_set(addr, addrinarray, - cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS), - 1); + cachemode2pgprot(set_type), 1); if (!ret && new_type == _PAGE_CACHE_MODE_WC) ret = change_page_attr_set_clr(addr, addrinarray, @@ -1527,10 +1528,22 @@ EXPORT_SYMBOL(set_memory_array_uc); int set_memory_array_wc(unsigned long *addr, int addrinarray) { + if (!pat_enabled) + return set_memory_array_uc(addr, addrinarray); + return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WC); } EXPORT_SYMBOL(set_memory_array_wc); +int set_memory_array_wt(unsigned long *addr, int addrinarray) +{ + if (!pat_enabled) + return set_memory_array_uc(addr, addrinarray); + + return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WT); +} +EXPORT_SYMBOL(set_memory_array_wt); + int _set_memory_wc(unsigned long addr, int numpages) { int ret; @@ -1574,6 +1587,37 @@ out_err: } EXPORT_SYMBOL(set_memory_wc); +int _set_memory_wt(unsigned long addr, int numpages) +{ + return change_page_attr_set(&addr, numpages, + cachemode2pgprot(_PAGE_CACHE_MODE_WT), 0); +} + +int set_memory_wt(unsigned long addr, int numpages) +{ + int ret; + + if (!pat_enabled) + return set_memory_uc(addr, numpages); + + ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE, + _PAGE_CACHE_MODE_WT, NULL); + if (ret) + goto out_err; + + ret = _set_memory_wt(addr, numpages); + if (ret) + goto out_free; + + return 0; + +out_free: + free_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE); +out_err: + return ret; +} +EXPORT_SYMBOL(set_memory_wt); + int _set_memory_wb(unsigned long addr, int numpages) { /* WB cache mode is hard wired to all cache attribute bits being 0 */ @@ -1666,6 +1710,7 @@ static int _set_pages_array(struct page **pages, int addrinarray, { unsigned long start; unsigned long end; + enum page_cache_mode set_type; int i; int free_idx; int ret; @@ -1679,8 +1724,12 @@ static int _set_pages_array(struct page **pages, int addrinarray, goto err_out; } + /* If WC, set to UC- first and then WC */ + set_type = (new_type == _PAGE_CACHE_MODE_WC) ? + _PAGE_CACHE_MODE_UC_MINUS : new_type; + ret = cpa_set_pages_array(pages, addrinarray, - cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS)); + cachemode2pgprot(set_type)); if (!ret && new_type == _PAGE_CACHE_MODE_WC) ret = change_page_attr_set_clr(NULL, addrinarray, cachemode2pgprot( @@ -1710,10 +1759,22 @@ EXPORT_SYMBOL(set_pages_array_uc); int set_pages_array_wc(struct page **pages, int addrinarray) { + if (!pat_enabled) + return set_pages_array_uc(pages, addrinarray); + return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WC); } EXPORT_SYMBOL(set_pages_array_wc); +int set_pages_array_wt(struct page **pages, int addrinarray) +{ + if (!pat_enabled) + return set_pages_array_uc(pages, addrinarray); + + return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WT); +} +EXPORT_SYMBOL(set_pages_array_wt); + int set_pages_wb(struct page *page, int numpages) { unsigned long addr = (unsigned long)page_address(page); -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by kanga.kvack.org (Postfix) with ESMTP id 1226A6B003A for ; Thu, 4 Sep 2014 14:47:42 -0400 (EDT) Received: by mail-yk0-f170.google.com with SMTP id 142so6378408ykq.15 for ; Thu, 04 Sep 2014 11:47:41 -0700 (PDT) Received: from g5t1625.atlanta.hp.com (g5t1625.atlanta.hp.com. [15.192.137.8]) by mx.google.com with ESMTPS id s26si13570443yhf.154.2014.09.04.11.47.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 11:47:41 -0700 (PDT) From: Toshi Kani Subject: [PATCH 5/5] x86, mm, pat: Add pgprot_writethrough() for WT Date: Thu, 4 Sep 2014 12:35:39 -0600 Message-Id: <1409855739-8985-6-git-send-email-toshi.kani@hp.com> In-Reply-To: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: owner-linux-mm@kvack.org List-ID: To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com, Toshi Kani This patch adds pgprot_writethrough() for setting WT to a given pgprot_t. Signed-off-by: Toshi Kani --- arch/x86/include/asm/pgtable_types.h | 3 +++ arch/x86/mm/pat.c | 10 ++++++++++ include/asm-generic/pgtable.h | 4 ++++ 3 files changed, 17 insertions(+) diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index bd2f50f..cc7c65d 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -394,6 +394,9 @@ extern int nx_enabled; #define pgprot_writecombine pgprot_writecombine extern pgprot_t pgprot_writecombine(pgprot_t prot); +#define pgprot_writethrough pgprot_writethrough +extern pgprot_t pgprot_writethrough(pgprot_t prot); + /* Indicate that x86 has its own track and untrack pfn vma functions */ #define __HAVE_PFNMAP_TRACKING diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c index 87b21dd..ed62ead 100644 --- a/arch/x86/mm/pat.c +++ b/arch/x86/mm/pat.c @@ -878,6 +878,16 @@ pgprot_t pgprot_writecombine(pgprot_t prot) } EXPORT_SYMBOL_GPL(pgprot_writecombine); +pgprot_t pgprot_writethrough(pgprot_t prot) +{ + if (pat_enabled) + return __pgprot(pgprot_val(prot) | + cachemode2protval(_PAGE_CACHE_MODE_WT)); + else + return pgprot_noncached(prot); +} +EXPORT_SYMBOL_GPL(pgprot_writethrough); + #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT) static struct memtype *memtype_get_idx(loff_t pos) diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index 53b2acc..1af0ed9 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b) #define pgprot_writecombine pgprot_noncached #endif +#ifndef pgprot_writethrough +#define pgprot_writethrough pgprot_noncached +#endif + /* * When walking page tables, get the address of the next boundary, * or the end address of the range if that comes earlier. Although no -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by kanga.kvack.org (Postfix) with ESMTP id D82146B0036 for ; Thu, 4 Sep 2014 14:57:24 -0400 (EDT) Received: by mail-lb0-f176.google.com with SMTP id s7so12207199lbd.35 for ; Thu, 04 Sep 2014 11:57:24 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by mx.google.com with ESMTPS id cf12si3884154lbb.19.2014.09.04.11.57.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 11:57:22 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id s7so11929231lbd.7 for ; Thu, 04 Sep 2014 11:57:22 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1409855739-8985-5-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> From: Andy Lutomirski Date: Thu, 4 Sep 2014 11:57:01 -0700 Message-ID: Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani wrote: > This patch adds set_memory_wt(), set_memory_array_wt(), and > set_pages_array_wt() for setting range(s) of memory to WT. > Possibly dumb question: I thought that set_memory_xyz was only for RAM. Is that incorrect? --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by kanga.kvack.org (Postfix) with ESMTP id 7B8696B0037 for ; Thu, 4 Sep 2014 15:07:35 -0400 (EDT) Received: by mail-yk0-f175.google.com with SMTP id 131so6396579ykp.34 for ; Thu, 04 Sep 2014 12:07:35 -0700 (PDT) Received: from g6t1526.atlanta.hp.com (g6t1526.atlanta.hp.com. [15.193.200.69]) by mx.google.com with ESMTPS id w4si13683729yhn.100.2014.09.04.12.07.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 12:07:35 -0700 (PDT) Message-ID: <1409857025.28990.125.camel@misato.fc.hp.com> Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT From: Toshi Kani Date: Thu, 04 Sep 2014 12:57:05 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote: > On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani wrote: > > This patch adds set_memory_wt(), set_memory_array_wt(), and > > set_pages_array_wt() for setting range(s) of memory to WT. > > > > Possibly dumb question: I thought that set_memory_xyz was only for > RAM. Is that incorrect? It works for non-RAM ranges as well. For instance, you can use set_memory_xyz() to change cache attribute for a non-RAM range mapped by ioremap_cache(). Thanks, -Toshi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by kanga.kvack.org (Postfix) with ESMTP id 545316B0036 for ; Thu, 4 Sep 2014 15:15:16 -0400 (EDT) Received: by mail-la0-f43.google.com with SMTP id gi9so1607924lab.30 for ; Thu, 04 Sep 2014 12:15:15 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by mx.google.com with ESMTPS id ee12si3808753lbd.126.2014.09.04.12.15.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 12:15:14 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so1644825lam.14 for ; Thu, 04 Sep 2014 12:15:14 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1409857025.28990.125.camel@misato.fc.hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> From: Andy Lutomirski Date: Thu, 4 Sep 2014 12:14:54 -0700 Message-ID: Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Thu, Sep 4, 2014 at 11:57 AM, Toshi Kani wrote: > On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote: >> On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani wrote: >> > This patch adds set_memory_wt(), set_memory_array_wt(), and >> > set_pages_array_wt() for setting range(s) of memory to WT. >> > >> >> Possibly dumb question: I thought that set_memory_xyz was only for >> RAM. Is that incorrect? > > It works for non-RAM ranges as well. For instance, you can use > set_memory_xyz() to change cache attribute for a non-RAM range mapped by > ioremap_cache(). OK -- I didn't realize that was legal. Do you, by any chance, have a test driver for this? For example, something that lets your reserve some WT memory at boot and mmap it? I wouldn't mind getting some benchmarks, and I can even throw it at the NV-DIMM box that's sitting under my desk :) --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by kanga.kvack.org (Postfix) with ESMTP id 897476B0036 for ; Thu, 4 Sep 2014 15:41:24 -0400 (EDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so20723765pab.29 for ; Thu, 04 Sep 2014 12:41:22 -0700 (PDT) Received: from g2t2352.austin.hp.com (g2t2352.austin.hp.com. [15.217.128.51]) by mx.google.com with ESMTPS id mk5si5251645pdb.238.2014.09.04.12.41.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 12:41:21 -0700 (PDT) Message-ID: <1409859049.28990.135.camel@misato.fc.hp.com> Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT From: Toshi Kani Date: Thu, 04 Sep 2014 13:30:49 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> Content-Type: multipart/mixed; boundary="=-Nrre2KoVOl8p9Z6mROCz" Mime-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk --=-Nrre2KoVOl8p9Z6mROCz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2014-09-04 at 12:14 -0700, Andy Lutomirski wrote: > On Thu, Sep 4, 2014 at 11:57 AM, Toshi Kani wrote: > > On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote: > >> On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani wrote: > >> > This patch adds set_memory_wt(), set_memory_array_wt(), and > >> > set_pages_array_wt() for setting range(s) of memory to WT. > >> > > >> > >> Possibly dumb question: I thought that set_memory_xyz was only for > >> RAM. Is that incorrect? > > > > It works for non-RAM ranges as well. For instance, you can use > > set_memory_xyz() to change cache attribute for a non-RAM range mapped by > > ioremap_cache(). > > OK -- I didn't realize that was legal. > > Do you, by any chance, have a test driver for this? For example, > something that lets your reserve some WT memory at boot and mmap it? > I wouldn't mind getting some benchmarks, and I can even throw it at > the NV-DIMM box that's sitting under my desk :) Yes, the attached file contains two test tools. Please update NVDIMM_ADDR to your NV-DIMM address in test-wt.c and test.c. 1) mmap via /dev/mem dev-mem-test/mem-wt.patch - kernel patch that tweaks /dev/mem dev-mem-test/test-wt.c - user program that mmaps a NVDIMM range w/ WT 2) Test driver for testing the interfaces interfaces-test/Makefile interfaces-test/test.c Thanks, -Toshi --=-Nrre2KoVOl8p9Z6mROCz Content-Type: application/x-compressed-tar; name="tests.tgz" Content-Disposition: attachment; filename="tests.tgz" Content-Transfer-Encoding: base64 H4sIAIm7CFQAA+1b7XObOBPvV/NX7KW9Dn5/ieN06ibTnOO2mcZOxkkv97wNQ0DEumJgQMTNXfu/ 30qAbTA4deLknubYDwRWq9Xqp11pFxydXFcnZFJlxGP1Zw9DDaTd3R3+t7m701j8G9GzZqvdaDW3 d3ba288a+NBqP4OdB7InRr7HVBfgGbO9MV0hd1v7D0r64vrzmymrOSrTxhscgy9wp9POWv9mY6c5 X/8W+kmz3cFmaGzQhkz6h6//O9eevIZzPjn4qFoU3oiJ1j7j/duxU9Psyb4knY+pB8ItQBur1hXx oI6ewx0GmA2+R+DiHCaq41DrCqZjYsGJcnj2r2FPwo6eQzRqUKLXpGq1KoHqauP6l1ed+mRSR6U1 Db4CUgvK2NgEg5okHEav4DO1POIyaltyucifdWIS8VgtSpJODQOq1SvKQK0vK75c5knU0skXIHqn RVS9VlNfEW23qUMTnbTd5hamaZLK5XKqtrdvodpp7FR2oRz8QQa1GDjjG09BfBRV04jnKY5rM0U1 TXtKdNljrq+xYKYlfq2Ab3n0yiI6mDZC6BhWRYJCwSXMdy1odCXAR2qAzKWr+4ZimOqVBy8jnItS tVBwtAnsgXJ68L6v9A56H/rK4OSwr3zqKYOj4aezrlTOlLk4F0M8p4ZODOidDN8dvVd+e9VRtls4 cL0k/d2OmtODUGz/5xd+AGibHUPs/+3M/b+120me/+1Wo5Xv/49Bz6mlmb5O4I1349XZjUO82nhf irMRIrbMnUxUa5nL6IQkuMzFUyHOMzSLmUkxndpLLJNexnm+RZHNeRI3i2oQbqZ84GvVBL6eTGHX FbyzHbzpSlK9Dj3V1HxTZQTYmAA/NohLLI3AJWFTggcWm9pCB6ASH1GQrm2qA7v2/Es5MUSJ8f6V 5Mgl1kzhNYrSn1JB9Kjus2vFIxpuwKw5e6gCa0QP3UVJPybqx2T9QJifCIkObwBHLMQHrFYrkBAr 7/ETj1NX+iYQOuPAccP5GW7Z0xABgacsJiFzRhGuCOPTsw1dvZFfzvFehOkP28KjrYi2zNXbTqRd tXQIjzaXIEoCd2rBhGqujdbZlo4LED8SxYUvaWBLAmcxO1zpLBuFJ2SbWAjW+WW4sPMOs+lxodDk APFauHylCEcow6yBQxzM/DmepxQHGhycnh39u18oyCheajZabXEpFgqIDbJg8MtMdvjr4dFgoBwc Ho4KjS+4MwYkRHsfDobv+3D+4ejsJ0nimcZEpVaACX8yMGeiaGscvJJTgdIUL2ziLDWKSwgkhxBH WcjmZMt2J5i43MCnXjXioocZOvqm7RBL3opywa0KpiOjw4vR1ygridT9EnUUj6u6ii4OtuP24sjD T8fHlQi7CpyOTs6VUf/g8Ku4uxgdnfcr6OyFAoooZx8ORv3DioBgAUKhMfRinLthuyDTvUYFps6e 0wX6Rg711z36B3qMPHWKReSXyzyOEDXM/DBYuJOEzrYX+iGyHNzbmCFvXbiUkdfwc7Nhmj5PiLX/ WjinsMf9TMA1wyGFIauNGGFCC6uM+LaUxmFH4hoqpqgP9wpgnfq/3eng+b/dajXz+v8xKLn+A/Uz 4SXGJse4pf5vNDut+frvtIL6fzvP/x6DhgeD/h5fecm+/L3KS8MXMucVa7b08df+6OzoZIjM7Vpz t9aoutp2WZLwMHgtFSboKVDtQR1TtPrE1n2TePUXctSpWL/0qanDYO+FfHpxWIRQJC8k/68oGf/8 8iD1X2b8t7Yx3Ofx327w+N9u5/Xfo9C8sDKp5X+pU4smSr2Af01cj9pWWlMQ2GktnqlepvE1e+Lg GePG21RvUtdUbUwM0/fGy23J6pDzJp5Qsn7mvJCWKyIvX5GWR4VmUBBigChYtOii0ICSquuuSL5n ObU2RofCbA23TTnBLAIX7yaFw6S80wbmaVhD4rXVDdJ5yjNHV0eOacq8dTF/jDJHJT11hD9nyeNB r9c/O1NOhr2+jKZxJYUwn/wW098K8knFsnHGRN6aTfc1hHmlSCmFaFXYE5Q5SxBNeUJ8P4weBI8k EmFqvwYa08VUPx2NOQweYfwtsO3eKKODQVCcciTmwIQTw9pSVD7zwfb29tJ0APJxVFFS8P44gc+8 PrM1OZyxeLfLIShW4P27U+VjfzTsHxfD1wU/BasRvVtODKqhJlgYcMqCsbg0LzkWW2Q5VkcWueIK NKOBsAcfBpUT15W3Yl3BUHED0OFnXQDIRW8xxNeyDPG1Oxvia+sbMr3MROTy7ohcZhjy2XAJkcM4 EvqSHkZtl2CpzNcj1bvSfWrea9GfFiTnAuF0Q19bGG5hs63MNtK4m4mQi+a7MGYw2VDzzBMx+rC+ ne8e4XQL8z035OAQtm/xFwQrEdHuhIh2GyJaBiLa3RHRHgWRO8CxGotUIO6KwuM4Bf8ON8fBuRLf 5RjwP9113IR3iIETaLpWTZnf8HOlIQ4PLgZhq5gBG7u2fzUOxDJ8jLele5mwPxXhCiRt+A7PE/Y9 KPALuxyafe8TEHXcEp8ih0wHTzTdOUpF7/uDtdHTdpbuwP4+BAf/h6N357Olv8MhfP9ZrH1C3mMW WQfnRh1XdV2VI7bCgxPv21WTeizKWStgVb7TvRdH+sH93OLJfcbCiuSVQxQrAALoilE6G+WzcY+B EljF4KV/oZCW3nK18YmFCldNKSghxKYNFN6ANXv7LvT9h/5vyVLhu1CGeb6NptHbgiNa4KwQidpl MS56zu0xEHV5qHgO9WdGddS+vsn3C95EbizWvbtuTGuPFtNaHtNPO6YzK9Soff0AyapP85heEdP+ o8W0n8f0047p7LdOUfvaAZL5zimP6XhMO+oV8dZPvR2D+0r4Ox+uA0olZ90oXx77Bw9yRGU5MBSc ZyASD/tusCmk7wlCW7QlxGFe2hFizcWSlf5C2tnwTuDMdwKctsJssZwyh6C8IvDja74URPFm2bk9 huI9Nh71MfXLQR9vXtveTYa8c6eQ//5TfPMh/xTO9Tzk1wv55aM+3rx2CG3+oH/iIb9G4r7xkH8S qXwe8muFfEp2H29eN4QeILd/EiHPIzL4embRxa9viV9W8NZwhmk/nkjj8/0ijR8rG1YIaLcI+CkC KYVJdvst/ZP6o2+oSQZPOZd52jJPfB8MfST818FvUvATrQD9GdJ8Ced7MfmyamV4a7AyM2Wiw6yR KxucHH467ivHR73+8Kwvb70/PYbrFu/0d//KLaeccsopp5xyyimnnHLKKaeccsrpn0t/ARaQiQsA UAAA --=-Nrre2KoVOl8p9Z6mROCz-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by kanga.kvack.org (Postfix) with ESMTP id 4C7326B0036 for ; Thu, 4 Sep 2014 16:11:43 -0400 (EDT) Received: by mail-pd0-f172.google.com with SMTP id v10so2067663pde.3 for ; Thu, 04 Sep 2014 13:11:43 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com. [66.111.4.25]) by mx.google.com with ESMTPS id ao2si15248pad.52.2014.09.04.13.11.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Sep 2014 13:11:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by gateway2.nyi.internal (Postfix) with ESMTP id 9B73720C5A for ; Thu, 4 Sep 2014 16:11:35 -0400 (EDT) Date: Thu, 4 Sep 2014 17:11:23 -0300 From: Henrique de Moraes Holschuh Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140904201123.GA9116@khazad-dum.debian.net> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1409855739-8985-2-git-send-email-toshi.kani@hp.com> Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com On Thu, 04 Sep 2014, Toshi Kani wrote: > This patch sets WT to the PA4 slot in the PAT MSR when the processor > is not affected by the PAT errata. The upper 4 slots of the PAT MSR > are continued to be unused on the following Intel processors. > > errata cpuid > -------------------------------------- > Pentium 2, A52 family 0x6, model 0x5 > Pentium 3, E27 family 0x6, model 0x7 > Pentium M, Y26 family 0x6, model 0x9 > Pentium 4, N46 family 0xf, model 0x0 > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- > per the default setup in __cachemode2pte_tbl[]. There are at least two PAT errata. The blacklist is in arch/x86/kernel/cpu/intel.c: if (c->x86 == 6 && c->x86_model < 15) clear_cpu_cap(c, X86_FEATURE_PAT); It covers model 13, which is not in your blacklist. It *is* possible that PAT would work on model 13, as I don't think it has any PAT errata listed and it was blacklisted "just in case" (from memory. I did not re-check), but this is untested, and unwise to enable on an aging platform. I am worried of uncharted territory, here. I'd actually advocate for not enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP is using them as well. Is this a real concern, or am I being overly cautious? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by kanga.kvack.org (Postfix) with ESMTP id D19696B0036 for ; Thu, 4 Sep 2014 16:21:55 -0400 (EDT) Received: by mail-pa0-f54.google.com with SMTP id fb1so20741729pad.13 for ; Thu, 04 Sep 2014 13:21:54 -0700 (PDT) Received: from mail.zytor.com (terminus.zytor.com. [2001:1868:205::10]) by mx.google.com with ESMTPS id bi17si5418433pdb.236.2014.09.04.13.21.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Sep 2014 13:21:53 -0700 (PDT) Message-ID: <5408C9C4.1010705@zytor.com> Date: Thu, 04 Sep 2014 13:21:24 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> In-Reply-To: <20140904201123.GA9116@khazad-dum.debian.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Henrique de Moraes Holschuh , Toshi Kani Cc: tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > > I am worried of uncharted territory, here. I'd actually advocate for not > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > is using them as well. Is this a real concern, or am I being overly > cautious? > It is extremely unlikely that we'd have PAT issues in 32-bit mode and not in 64-bit mode on the same CPU. As far as I know, the current blacklist rule is very conservative due to lack of testing more than anything else. -hpa -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by kanga.kvack.org (Postfix) with ESMTP id 4F08F6B0036 for ; Thu, 4 Sep 2014 16:42:18 -0400 (EDT) Received: by mail-oi0-f54.google.com with SMTP id a3so7235140oib.27 for ; Thu, 04 Sep 2014 13:42:18 -0700 (PDT) Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com. [15.201.208.53]) by mx.google.com with ESMTPS id tb8si171221obc.8.2014.09.04.13.42.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 13:42:17 -0700 (PDT) Message-ID: <1409862708.28990.141.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani Date: Thu, 04 Sep 2014 14:31:48 -0600 In-Reply-To: <20140904201123.GA9116@khazad-dum.debian.net> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Henrique de Moraes Holschuh Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote: > On Thu, 04 Sep 2014, Toshi Kani wrote: > > This patch sets WT to the PA4 slot in the PAT MSR when the processor > > is not affected by the PAT errata. The upper 4 slots of the PAT MSR > > are continued to be unused on the following Intel processors. > > > > errata cpuid > > -------------------------------------- > > Pentium 2, A52 family 0x6, model 0x5 > > Pentium 3, E27 family 0x6, model 0x7 > > Pentium M, Y26 family 0x6, model 0x9 > > Pentium 4, N46 family 0xf, model 0x0 > > > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- > > per the default setup in __cachemode2pte_tbl[]. > > There are at least two PAT errata. The blacklist is in > arch/x86/kernel/cpu/intel.c: > > if (c->x86 == 6 && c->x86_model < 15) > clear_cpu_cap(c, X86_FEATURE_PAT); > > It covers model 13, which is not in your blacklist. > > It *is* possible that PAT would work on model 13, as I don't think it has > any PAT errata listed and it was blacklisted "just in case" (from memory. I > did not re-check), but this is untested, and unwise to enable on an aging > platform. > > I am worried of uncharted territory, here. I'd actually advocate for not > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > is using them as well. Is this a real concern, or am I being overly > cautious? The blacklist you pointed out covers a different PAT errata, and is still effective after this change. pat_init() will call pat_disable() and the PAT will continue to be disabled on these processors. There is no change for them. My blacklist covers the PAT errata that makes the upper four bit unusable when the PAT is enabled. Thanks, -Toshi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by kanga.kvack.org (Postfix) with ESMTP id BD0F46B0036 for ; Thu, 4 Sep 2014 16:50:38 -0400 (EDT) Received: by mail-la0-f49.google.com with SMTP id b17so12545518lan.22 for ; Thu, 04 Sep 2014 13:50:38 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by mx.google.com with ESMTPS id tc3si52779lbb.103.2014.09.04.13.50.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 13:50:37 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so12464879lbd.34 for ; Thu, 04 Sep 2014 13:50:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1409862708.28990.141.camel@misato.fc.hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <1409862708.28990.141.camel@misato.fc.hp.com> From: Andy Lutomirski Date: Thu, 4 Sep 2014 13:50:16 -0700 Message-ID: Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Thu, Sep 4, 2014 at 1:31 PM, Toshi Kani wrote: > On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote: >> On Thu, 04 Sep 2014, Toshi Kani wrote: >> > This patch sets WT to the PA4 slot in the PAT MSR when the processor >> > is not affected by the PAT errata. The upper 4 slots of the PAT MSR >> > are continued to be unused on the following Intel processors. >> > >> > errata cpuid >> > -------------------------------------- >> > Pentium 2, A52 family 0x6, model 0x5 >> > Pentium 3, E27 family 0x6, model 0x7 >> > Pentium M, Y26 family 0x6, model 0x9 >> > Pentium 4, N46 family 0xf, model 0x0 >> > >> > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- >> > per the default setup in __cachemode2pte_tbl[]. >> >> There are at least two PAT errata. The blacklist is in >> arch/x86/kernel/cpu/intel.c: >> >> if (c->x86 == 6 && c->x86_model < 15) >> clear_cpu_cap(c, X86_FEATURE_PAT); >> >> It covers model 13, which is not in your blacklist. >> >> It *is* possible that PAT would work on model 13, as I don't think it has >> any PAT errata listed and it was blacklisted "just in case" (from memory. I >> did not re-check), but this is untested, and unwise to enable on an aging >> platform. >> >> I am worried of uncharted territory, here. I'd actually advocate for not >> enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP >> is using them as well. Is this a real concern, or am I being overly >> cautious? > > The blacklist you pointed out covers a different PAT errata, and is > still effective after this change. pat_init() will call pat_disable() > and the PAT will continue to be disabled on these processors. There is > no change for them. > > My blacklist covers the PAT errata that makes the upper four bit > unusable when the PAT is enabled. > IIRC a lot of the errata only matter if we try to use various PAT bits in intermediate page table entries to change the caching mode of, say, the PTE pages. If we're doing that, something's very wrong, errata or otherwise. --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by kanga.kvack.org (Postfix) with ESMTP id C0AA46B0036 for ; Thu, 4 Sep 2014 19:19:40 -0400 (EDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so20848881pab.17 for ; Thu, 04 Sep 2014 16:19:40 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com. [66.111.4.25]) by mx.google.com with ESMTPS id ad7si584373pbd.81.2014.09.04.16.19.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Sep 2014 16:19:39 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id B31D220825 for ; Thu, 4 Sep 2014 19:19:35 -0400 (EDT) Date: Thu, 4 Sep 2014 20:19:23 -0300 From: Henrique de Moraes Holschuh Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140904231923.GA15320@khazad-dum.debian.net> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5408C9C4.1010705@zytor.com> Sender: owner-linux-mm@kvack.org List-ID: To: "H. Peter Anvin" Cc: Toshi Kani , tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com On Thu, 04 Sep 2014, H. Peter Anvin wrote: > On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > > I am worried of uncharted territory, here. I'd actually advocate for not > > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > > is using them as well. Is this a real concern, or am I being overly > > cautious? > > It is extremely unlikely that we'd have PAT issues in 32-bit mode and > not in 64-bit mode on the same CPU. Sure, but is it really a good idea to enable this on the *old* non-64-bit capable processors (note: I don't mean x86-64 processors operating in 32-bit mode) ? > As far as I know, the current blacklist rule is very conservative due to > lack of testing more than anything else. I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted from using PAT :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by kanga.kvack.org (Postfix) with ESMTP id BFD2E6B0036 for ; Thu, 4 Sep 2014 19:35:06 -0400 (EDT) Received: by mail-la0-f44.google.com with SMTP id hz20so12873890lab.17 for ; Thu, 04 Sep 2014 16:35:05 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by mx.google.com with ESMTPS id g9si504016lbv.86.2014.09.04.16.35.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 16:35:04 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id b17so12748532lan.22 for ; Thu, 04 Sep 2014 16:35:04 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140904231923.GA15320@khazad-dum.debian.net> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> From: Andy Lutomirski Date: Thu, 4 Sep 2014 16:34:43 -0700 Message-ID: Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Henrique de Moraes Holschuh Cc: "H. Peter Anvin" , Toshi Kani , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh wrote: > On Thu, 04 Sep 2014, H. Peter Anvin wrote: >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: >> > I am worried of uncharted territory, here. I'd actually advocate for not >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP >> > is using them as well. Is this a real concern, or am I being overly >> > cautious? >> >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and >> not in 64-bit mode on the same CPU. > > Sure, but is it really a good idea to enable this on the *old* non-64-bit > capable processors (note: I don't mean x86-64 processors operating in 32-bit > mode) ? > >> As far as I know, the current blacklist rule is very conservative due to >> lack of testing more than anything else. > > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted > from using PAT :-) At the very least, anyone who plugs an NV-DIMM into a 32-bit machine is nuts, and not just because I'd be somewhat amazed if it even physically fits into the slot. :) --Andy > > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by kanga.kvack.org (Postfix) with ESMTP id 5C0796B0036 for ; Thu, 4 Sep 2014 19:38:05 -0400 (EDT) Received: by mail-yh0-f42.google.com with SMTP id z6so107355yhz.29 for ; Thu, 04 Sep 2014 16:38:05 -0700 (PDT) Received: from g5t1626.atlanta.hp.com (g5t1626.atlanta.hp.com. [15.192.137.9]) by mx.google.com with ESMTPS id c77si560798yha.32.2014.09.04.16.38.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 16:38:04 -0700 (PDT) Message-ID: <1409873255.28990.158.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani Date: Thu, 04 Sep 2014 17:27:35 -0600 In-Reply-To: <1409862708.28990.141.camel@misato.fc.hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <1409862708.28990.141.camel@misato.fc.hp.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Henrique de Moraes Holschuh Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com On Thu, 2014-09-04 at 14:31 -0600, Toshi Kani wrote: > On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote: > > On Thu, 04 Sep 2014, Toshi Kani wrote: > > > This patch sets WT to the PA4 slot in the PAT MSR when the processor > > > is not affected by the PAT errata. The upper 4 slots of the PAT MSR > > > are continued to be unused on the following Intel processors. > > > > > > errata cpuid > > > -------------------------------------- > > > Pentium 2, A52 family 0x6, model 0x5 > > > Pentium 3, E27 family 0x6, model 0x7 > > > Pentium M, Y26 family 0x6, model 0x9 > > > Pentium 4, N46 family 0xf, model 0x0 > > > > > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- > > > per the default setup in __cachemode2pte_tbl[]. > > > > There are at least two PAT errata. The blacklist is in > > arch/x86/kernel/cpu/intel.c: > > > > if (c->x86 == 6 && c->x86_model < 15) > > clear_cpu_cap(c, X86_FEATURE_PAT); > > > > It covers model 13, which is not in your blacklist. > > > > It *is* possible that PAT would work on model 13, as I don't think it has > > any PAT errata listed and it was blacklisted "just in case" (from memory. I > > did not re-check), but this is untested, and unwise to enable on an aging > > platform. > > > > I am worried of uncharted territory, here. I'd actually advocate for not > > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > > is using them as well. Is this a real concern, or am I being overly > > cautious? > > The blacklist you pointed out covers a different PAT errata, and is > still effective after this change. pat_init() will call pat_disable() > and the PAT will continue to be disabled on these processors. There is > no change for them. > > My blacklist covers the PAT errata that makes the upper four bit > unusable when the PAT is enabled. I checked more carefully, and it turns out that the processors that have the WC bug with PAT/MTRR also have the upper four bit bug in PAT as well. The updated blacklist is: errata cpuid -------------------------------------- Pentium 2, A52 family 0x6, model 0x5 Pentium 3, E27 family 0x6, model 0x7, 0x8 Pentium 3 Xeon, G26 family 0x6, model 0x7, 0x8, 0xa Pentium M, Y26 family 0x6, model 0x9 Pentium M 90nm, X9 family 0x6, model 0xd Pentium 4, N46 family 0xf, model 0x0 So, the check can be the same as cpu/intel.c, except that early Pentium 4 steppings also have the upper four bit bug. I will update the check. In any case, this check is only meaningful for P4 since the PAT is disabled for P2/3/M. Thanks Henrique for pointing this out! -Toshi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by kanga.kvack.org (Postfix) with ESMTP id A723C6B0036 for ; Thu, 4 Sep 2014 20:40:21 -0400 (EDT) Received: by mail-ob0-f179.google.com with SMTP id uz6so8157913obc.24 for ; Thu, 04 Sep 2014 17:40:21 -0700 (PDT) Received: from g4t3426.houston.hp.com (g4t3426.houston.hp.com. [15.201.208.54]) by mx.google.com with ESMTPS id x5si774405obk.0.2014.09.04.17.40.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 17:40:21 -0700 (PDT) Message-ID: <1409876991.28990.172.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani Date: Thu, 04 Sep 2014 18:29:51 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Thu, 2014-09-04 at 16:34 -0700, Andy Lutomirski wrote: > On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh > wrote: > > On Thu, 04 Sep 2014, H. Peter Anvin wrote: > >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > >> > I am worried of uncharted territory, here. I'd actually advocate for not > >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > >> > is using them as well. Is this a real concern, or am I being overly > >> > cautious? > >> > >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and > >> not in 64-bit mode on the same CPU. > > > > Sure, but is it really a good idea to enable this on the *old* non-64-bit > > capable processors (note: I don't mean x86-64 processors operating in 32-bit > > mode) ? > > > >> As far as I know, the current blacklist rule is very conservative due to > >> lack of testing more than anything else. > > > > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted > > from using PAT :-) > > At the very least, anyone who plugs an NV-DIMM into a 32-bit machine > is nuts, and not just because I'd be somewhat amazed if it even > physically fits into the slot. :) According to the spec, the upper four entries bug was fixed in Pentium 4 model 0x1. So, the remaining Intel 32-bit processors that may enable the upper four entries are Pentium 4 model 0x1-4. Should we disable it for all Pentium 4 models? Thanks, -Toshi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by kanga.kvack.org (Postfix) with ESMTP id BC4E56B0036 for ; Thu, 4 Sep 2014 20:52:18 -0400 (EDT) Received: by mail-la0-f53.google.com with SMTP id q1so4272395lam.26 for ; Thu, 04 Sep 2014 17:52:17 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by mx.google.com with ESMTPS id ei11si810397lad.2.2014.09.04.17.52.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 17:52:16 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id pn19so12933096lab.18 for ; Thu, 04 Sep 2014 17:52:15 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1409876991.28990.172.camel@misato.fc.hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> From: Andy Lutomirski Date: Thu, 4 Sep 2014 17:51:55 -0700 Message-ID: Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Thu, Sep 4, 2014 at 5:29 PM, Toshi Kani wrote: > On Thu, 2014-09-04 at 16:34 -0700, Andy Lutomirski wrote: >> On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh >> wrote: >> > On Thu, 04 Sep 2014, H. Peter Anvin wrote: >> >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: >> >> > I am worried of uncharted territory, here. I'd actually advocate for not >> >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP >> >> > is using them as well. Is this a real concern, or am I being overly >> >> > cautious? >> >> >> >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and >> >> not in 64-bit mode on the same CPU. >> > >> > Sure, but is it really a good idea to enable this on the *old* non-64-bit >> > capable processors (note: I don't mean x86-64 processors operating in 32-bit >> > mode) ? >> > >> >> As far as I know, the current blacklist rule is very conservative due to >> >> lack of testing more than anything else. >> > >> > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted >> > from using PAT :-) >> >> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine >> is nuts, and not just because I'd be somewhat amazed if it even >> physically fits into the slot. :) > > According to the spec, the upper four entries bug was fixed in Pentium 4 > model 0x1. So, the remaining Intel 32-bit processors that may enable > the upper four entries are Pentium 4 model 0x1-4. Should we disable it > for all Pentium 4 models? Assuming that this is Pentium 4 erratum N46, then there may be another option: use slot 7 instead of slot 4 for WT. Then, even if somehow the blacklist screws up, the worst that happens is that a WT page gets interpreted as UC. I suppose this could cause aliasing issues, but can't cause problems for people who don't use the high entries in the first place. --Andy > > Thanks, > -Toshi > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by kanga.kvack.org (Postfix) with ESMTP id 374A26B0036 for ; Fri, 5 Sep 2014 06:23:54 -0400 (EDT) Received: by mail-we0-f179.google.com with SMTP id t60so11451888wes.24 for ; Fri, 05 Sep 2014 03:23:53 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [2a00:1450:400c:c05::231]) by mx.google.com with ESMTPS id m1si1316049wje.125.2014.09.05.03.23.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Sep 2014 03:23:52 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so2707552wib.4 for ; Fri, 05 Sep 2014 03:23:51 -0700 (PDT) Date: Fri, 5 Sep 2014 12:23:47 +0200 From: Ingo Molnar Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140905102347.GA30096@gmail.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <1409862708.28990.141.camel@misato.fc.hp.com> <1409873255.28990.158.camel@misato.fc.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1409873255.28990.158.camel@misato.fc.hp.com> Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: Henrique de Moraes Holschuh , hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com * Toshi Kani wrote: > On Thu, 2014-09-04 at 14:31 -0600, Toshi Kani wrote: > > On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote: > > > On Thu, 04 Sep 2014, Toshi Kani wrote: > > > > This patch sets WT to the PA4 slot in the PAT MSR when the processor > > > > is not affected by the PAT errata. The upper 4 slots of the PAT MSR > > > > are continued to be unused on the following Intel processors. > > > > > > > > errata cpuid > > > > -------------------------------------- > > > > Pentium 2, A52 family 0x6, model 0x5 > > > > Pentium 3, E27 family 0x6, model 0x7 > > > > Pentium M, Y26 family 0x6, model 0x9 > > > > Pentium 4, N46 family 0xf, model 0x0 > > > > > > > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- > > > > per the default setup in __cachemode2pte_tbl[]. > > > > > > There are at least two PAT errata. The blacklist is in > > > arch/x86/kernel/cpu/intel.c: > > > > > > if (c->x86 == 6 && c->x86_model < 15) > > > clear_cpu_cap(c, X86_FEATURE_PAT); > > > > > > It covers model 13, which is not in your blacklist. > > > > > > It *is* possible that PAT would work on model 13, as I don't think it has > > > any PAT errata listed and it was blacklisted "just in case" (from memory. I > > > did not re-check), but this is untested, and unwise to enable on an aging > > > platform. > > > > > > I am worried of uncharted territory, here. I'd actually advocate for not > > > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > > > is using them as well. Is this a real concern, or am I being overly > > > cautious? > > > > The blacklist you pointed out covers a different PAT errata, and is > > still effective after this change. pat_init() will call pat_disable() > > and the PAT will continue to be disabled on these processors. There is > > no change for them. > > > > My blacklist covers the PAT errata that makes the upper four bit > > unusable when the PAT is enabled. > > I checked more carefully, and it turns out that the processors > that have the WC bug with PAT/MTRR also have the upper four bit > bug in PAT as well. The updated blacklist is: > > errata cpuid > -------------------------------------- > Pentium 2, A52 family 0x6, model 0x5 > Pentium 3, E27 family 0x6, model 0x7, 0x8 > Pentium 3 Xeon, G26 family 0x6, model 0x7, 0x8, 0xa > Pentium M, Y26 family 0x6, model 0x9 > Pentium M 90nm, X9 family 0x6, model 0xd > Pentium 4, N46 family 0xf, model 0x0 > > So, the check can be the same as cpu/intel.c, except that early > Pentium 4 steppings also have the upper four bit bug. I will > update the check. In any case, this check is only meaningful > for P4 since the PAT is disabled for P2/3/M. Any reason why we have to create such a sharp boundary, instead of simply saying: 'disable PAT on all x86 CPU families that have at least one buggy model'? That would nicely sort out all the broken CPUs, and would make it highly unlikely that we'd accidentally forget about a model or two. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by kanga.kvack.org (Postfix) with ESMTP id C2A5A6B0038 for ; Fri, 5 Sep 2014 10:01:14 -0400 (EDT) Received: by mail-ob0-f178.google.com with SMTP id uy5so8686171obc.9 for ; Fri, 05 Sep 2014 07:01:14 -0700 (PDT) Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com. [15.201.208.53]) by mx.google.com with ESMTPS id mp4si3185190obb.24.2014.09.05.07.01.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Sep 2014 07:01:13 -0700 (PDT) Message-ID: <1409925023.28990.176.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani Date: Fri, 05 Sep 2014 07:50:23 -0600 In-Reply-To: <20140905102347.GA30096@gmail.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <1409862708.28990.141.camel@misato.fc.hp.com> <1409873255.28990.158.camel@misato.fc.hp.com> <20140905102347.GA30096@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Henrique de Moraes Holschuh , hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com On Fri, 2014-09-05 at 12:23 +0200, Ingo Molnar wrote: > * Toshi Kani wrote: > > > On Thu, 2014-09-04 at 14:31 -0600, Toshi Kani wrote: > > > On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote: > > > > On Thu, 04 Sep 2014, Toshi Kani wrote: > > > > > This patch sets WT to the PA4 slot in the PAT MSR when the processor > > > > > is not affected by the PAT errata. The upper 4 slots of the PAT MSR > > > > > are continued to be unused on the following Intel processors. > > > > > > > > > > errata cpuid > > > > > -------------------------------------- > > > > > Pentium 2, A52 family 0x6, model 0x5 > > > > > Pentium 3, E27 family 0x6, model 0x7 > > > > > Pentium M, Y26 family 0x6, model 0x9 > > > > > Pentium 4, N46 family 0xf, model 0x0 > > > > > > > > > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- > > > > > per the default setup in __cachemode2pte_tbl[]. > > > > > > > > There are at least two PAT errata. The blacklist is in > > > > arch/x86/kernel/cpu/intel.c: > > > > > > > > if (c->x86 == 6 && c->x86_model < 15) > > > > clear_cpu_cap(c, X86_FEATURE_PAT); > > > > > > > > It covers model 13, which is not in your blacklist. > > > > > > > > It *is* possible that PAT would work on model 13, as I don't think it has > > > > any PAT errata listed and it was blacklisted "just in case" (from memory. I > > > > did not re-check), but this is untested, and unwise to enable on an aging > > > > platform. > > > > > > > > I am worried of uncharted territory, here. I'd actually advocate for not > > > > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > > > > is using them as well. Is this a real concern, or am I being overly > > > > cautious? > > > > > > The blacklist you pointed out covers a different PAT errata, and is > > > still effective after this change. pat_init() will call pat_disable() > > > and the PAT will continue to be disabled on these processors. There is > > > no change for them. > > > > > > My blacklist covers the PAT errata that makes the upper four bit > > > unusable when the PAT is enabled. > > > > I checked more carefully, and it turns out that the processors > > that have the WC bug with PAT/MTRR also have the upper four bit > > bug in PAT as well. The updated blacklist is: > > > > errata cpuid > > -------------------------------------- > > Pentium 2, A52 family 0x6, model 0x5 > > Pentium 3, E27 family 0x6, model 0x7, 0x8 > > Pentium 3 Xeon, G26 family 0x6, model 0x7, 0x8, 0xa > > Pentium M, Y26 family 0x6, model 0x9 > > Pentium M 90nm, X9 family 0x6, model 0xd > > Pentium 4, N46 family 0xf, model 0x0 > > > > So, the check can be the same as cpu/intel.c, except that early > > Pentium 4 steppings also have the upper four bit bug. I will > > update the check. In any case, this check is only meaningful > > for P4 since the PAT is disabled for P2/3/M. > > Any reason why we have to create such a sharp boundary, instead > of simply saying: 'disable PAT on all x86 CPU families that have > at least one buggy model'? > > That would nicely sort out all the broken CPUs, and would make it > highly unlikely that we'd accidentally forget about a model or > two. Agreed. I will disable this feature on all Pentium 4 models as well. I do not think there is any necessity to enable it on Pentium 4. Thanks, -Toshi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by kanga.kvack.org (Postfix) with ESMTP id 174A06B0038 for ; Fri, 5 Sep 2014 10:11:08 -0400 (EDT) Received: by mail-pa0-f43.google.com with SMTP id et14so22298574pad.16 for ; Fri, 05 Sep 2014 07:11:06 -0700 (PDT) Received: from g2t2354.austin.hp.com (g2t2354.austin.hp.com. [15.217.128.53]) by mx.google.com with ESMTPS id f5si4571380pat.14.2014.09.05.07.11.03 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Sep 2014 07:11:04 -0700 (PDT) Message-ID: <1409925614.28990.184.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani Date: Fri, 05 Sep 2014 08:00:14 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Thu, 2014-09-04 at 17:51 -0700, Andy Lutomirski wrote: > On Thu, Sep 4, 2014 at 5:29 PM, Toshi Kani wrote: > > On Thu, 2014-09-04 at 16:34 -0700, Andy Lutomirski wrote: > >> On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh > >> wrote: > >> > On Thu, 04 Sep 2014, H. Peter Anvin wrote: > >> >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > >> >> > I am worried of uncharted territory, here. I'd actually advocate for not > >> >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > >> >> > is using them as well. Is this a real concern, or am I being overly > >> >> > cautious? > >> >> > >> >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and > >> >> not in 64-bit mode on the same CPU. > >> > > >> > Sure, but is it really a good idea to enable this on the *old* non-64-bit > >> > capable processors (note: I don't mean x86-64 processors operating in 32-bit > >> > mode) ? > >> > > >> >> As far as I know, the current blacklist rule is very conservative due to > >> >> lack of testing more than anything else. > >> > > >> > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted > >> > from using PAT :-) > >> > >> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine > >> is nuts, and not just because I'd be somewhat amazed if it even > >> physically fits into the slot. :) > > > > According to the spec, the upper four entries bug was fixed in Pentium 4 > > model 0x1. So, the remaining Intel 32-bit processors that may enable > > the upper four entries are Pentium 4 model 0x1-4. Should we disable it > > for all Pentium 4 models? > > Assuming that this is Pentium 4 erratum N46, then there may be another > option: use slot 7 instead of slot 4 for WT. Then, even if somehow > the blacklist screws up, the worst that happens is that a WT page gets > interpreted as UC. I suppose this could cause aliasing issues, but > can't cause problems for people who don't use the high entries in the > first place. That's a fine idea, but as Ingo also suggested, I am going to disable this feature on all Pentium 4 models. That should give us a safety margin. Using slot 4 has a benefit that it keeps the PAT setup consistent with Xen. Thanks, -Toshi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by kanga.kvack.org (Postfix) with ESMTP id 1A7BC6B0036 for ; Fri, 5 Sep 2014 11:07:55 -0400 (EDT) Received: by mail-pd0-f182.google.com with SMTP id fp1so15974622pdb.27 for ; Fri, 05 Sep 2014 08:07:54 -0700 (PDT) Received: from mail.zytor.com (terminus.zytor.com. [2001:1868:205::10]) by mx.google.com with ESMTPS id k5si4752771pdn.89.2014.09.05.08.07.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Sep 2014 08:07:52 -0700 (PDT) Message-ID: <5409D197.2060900@zytor.com> Date: Fri, 05 Sep 2014 08:07:03 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> <1409925614.28990.184.camel@misato.fc.hp.com> In-Reply-To: <1409925614.28990.184.camel@misato.fc.hp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani , Andy Lutomirski Cc: Henrique de Moraes Holschuh , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On 09/05/2014 07:00 AM, Toshi Kani wrote: > > That's a fine idea, but as Ingo also suggested, I am going to disable > this feature on all Pentium 4 models. That should give us a safety > margin. Using slot 4 has a benefit that it keeps the PAT setup > consistent with Xen. > Slot 4 is also the maximally problematic one, because it is the one that might be incorrectly invoked for the page tables themselves. -hpa -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by kanga.kvack.org (Postfix) with ESMTP id 590086B0036 for ; Fri, 5 Sep 2014 11:33:24 -0400 (EDT) Received: by mail-oi0-f46.google.com with SMTP id h136so7881582oig.5 for ; Fri, 05 Sep 2014 08:33:24 -0700 (PDT) Received: from g4t3426.houston.hp.com (g4t3426.houston.hp.com. [15.201.208.54]) by mx.google.com with ESMTPS id g6si3536908obh.55.2014.09.05.08.33.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Sep 2014 08:33:23 -0700 (PDT) Message-ID: <1409930574.28990.192.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani Date: Fri, 05 Sep 2014 09:22:54 -0600 In-Reply-To: <5409D197.2060900@zytor.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> <1409925614.28990.184.camel@misato.fc.hp.com> <5409D197.2060900@zytor.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "H. Peter Anvin" Cc: Andy Lutomirski , Henrique de Moraes Holschuh , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote: > On 09/05/2014 07:00 AM, Toshi Kani wrote: > > > > That's a fine idea, but as Ingo also suggested, I am going to disable > > this feature on all Pentium 4 models. That should give us a safety > > margin. Using slot 4 has a benefit that it keeps the PAT setup > > consistent with Xen. > > > > Slot 4 is also the maximally problematic one, because it is the one that > might be incorrectly invoked for the page tables themselves. Good point. I wonder if Xen folks feel strongly about keeping the PAT setup consistent with the kernel. If not, we may choose to use slot 6 (or 7). Thanks, -Toshi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by kanga.kvack.org (Postfix) with ESMTP id AB3D66B0036 for ; Fri, 5 Sep 2014 11:41:57 -0400 (EDT) Received: by mail-oa0-f45.google.com with SMTP id n16so8629975oag.32 for ; Fri, 05 Sep 2014 08:41:57 -0700 (PDT) Received: from mail.zytor.com (terminus.zytor.com. [2001:1868:205::10]) by mx.google.com with ESMTPS id jy10si4811535pbc.150.2014.09.05.08.41.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Sep 2014 08:41:55 -0700 (PDT) Message-ID: <5409D99C.10305@zytor.com> Date: Fri, 05 Sep 2014 08:41:16 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> <1409925614.28990.184.camel@misato.fc.hp.com> <5409D197.2060900@zytor.com> <1409930574.28990.192.camel@misato.fc.hp.com> In-Reply-To: <1409930574.28990.192.camel@misato.fc.hp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: Andy Lutomirski , Henrique de Moraes Holschuh , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On 09/05/2014 08:22 AM, Toshi Kani wrote: > On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote: >> On 09/05/2014 07:00 AM, Toshi Kani wrote: >>> >>> That's a fine idea, but as Ingo also suggested, I am going to disable >>> this feature on all Pentium 4 models. That should give us a safety >>> margin. Using slot 4 has a benefit that it keeps the PAT setup >>> consistent with Xen. >>> >> >> Slot 4 is also the maximally problematic one, because it is the one that >> might be incorrectly invoked for the page tables themselves. > > Good point. I wonder if Xen folks feel strongly about keeping the PAT > setup consistent with the kernel. If not, we may choose to use slot 6 > (or 7). > Who cares what the Xen folks "feel strongly about"? If strong feelings were a design criterion Xen support would have been pulled from the kernel a long, long time ago. The important thing is how to design for the situation that we currently have to live with. -hpa -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by kanga.kvack.org (Postfix) with ESMTP id E78F26B0036 for ; Fri, 5 Sep 2014 11:53:22 -0400 (EDT) Received: by mail-yh0-f47.google.com with SMTP id c41so7543960yho.34 for ; Fri, 05 Sep 2014 08:53:22 -0700 (PDT) Received: from g6t1524.atlanta.hp.com (g6t1524.atlanta.hp.com. [15.193.200.67]) by mx.google.com with ESMTPS id c29si2127609yha.187.2014.09.05.08.53.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Sep 2014 08:53:22 -0700 (PDT) Message-ID: <1409931772.28990.197.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani Date: Fri, 05 Sep 2014 09:42:52 -0600 In-Reply-To: <5409D99C.10305@zytor.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> <1409925614.28990.184.camel@misato.fc.hp.com> <5409D197.2060900@zytor.com> <1409930574.28990.192.camel@misato.fc.hp.com> <5409D99C.10305@zytor.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "H. Peter Anvin" Cc: Andy Lutomirski , Henrique de Moraes Holschuh , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Fri, 2014-09-05 at 08:41 -0700, H. Peter Anvin wrote: > On 09/05/2014 08:22 AM, Toshi Kani wrote: > > On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote: > >> On 09/05/2014 07:00 AM, Toshi Kani wrote: > >>> > >>> That's a fine idea, but as Ingo also suggested, I am going to disable > >>> this feature on all Pentium 4 models. That should give us a safety > >>> margin. Using slot 4 has a benefit that it keeps the PAT setup > >>> consistent with Xen. > >>> > >> > >> Slot 4 is also the maximally problematic one, because it is the one that > >> might be incorrectly invoked for the page tables themselves. > > > > Good point. I wonder if Xen folks feel strongly about keeping the PAT > > setup consistent with the kernel. If not, we may choose to use slot 6 > > (or 7). > > > > Who cares what the Xen folks "feel strongly about"? If strong feelings > were a design criterion Xen support would have been pulled from the > kernel a long, long time ago. > > The important thing is how to design for the situation that we currently > have to live with. I see. Then, I am going to use slot 7 for WT as suggested by Andy. I think it is the safest slot as slot 3 is UC and is not currently used. Thanks, -Toshi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by kanga.kvack.org (Postfix) with ESMTP id 364856B0035 for ; Sun, 7 Sep 2014 04:49:36 -0400 (EDT) Received: by mail-we0-f172.google.com with SMTP id w62so1109898wes.31 for ; Sun, 07 Sep 2014 01:49:35 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by mx.google.com with ESMTPS id e12si9383707wik.70.2014.09.07.01.49.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 01:49:34 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so1319806wiv.2 for ; Sun, 07 Sep 2014 01:49:34 -0700 (PDT) Message-ID: <540C1C01.1000308@plexistor.com> Date: Sun, 07 Sep 2014 11:49:05 +0300 From: Yigal Korman MIME-Version: 1.0 Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> In-Reply-To: <1409857025.28990.125.camel@misato.fc.hp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani , Andy Lutomirski Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt If it's possible, can you please update pat.txt as part of the patch? Thank you, Yigal On 04/09/2014 21:57, Toshi Kani wrote: > On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote: >> On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani wrote: >>> This patch adds set_memory_wt(), set_memory_array_wt(), and >>> set_pages_array_wt() for setting range(s) of memory to WT. >>> >> Possibly dumb question: I thought that set_memory_xyz was only for >> RAM. Is that incorrect? > It works for non-RAM ranges as well. For instance, you can use > set_memory_xyz() to change cache attribute for a non-RAM range mapped by > ioremap_cache(). > > Thanks, > -Toshi > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by kanga.kvack.org (Postfix) with ESMTP id 84C886B0035 for ; Sun, 7 Sep 2014 09:59:09 -0400 (EDT) Received: by mail-pa0-f49.google.com with SMTP id kq14so25390145pab.36 for ; Sun, 07 Sep 2014 06:59:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com. [66.111.4.25]) by mx.google.com with ESMTPS id zp8si13151382pac.130.2014.09.07.06.59.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Sep 2014 06:59:07 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by gateway2.nyi.internal (Postfix) with ESMTP id C71D420723 for ; Sun, 7 Sep 2014 09:59:03 -0400 (EDT) Date: Sun, 7 Sep 2014 10:58:50 -0300 From: Henrique de Moraes Holschuh Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140907135850.GA23026@khazad-dum.debian.net> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <1409862708.28990.141.camel@misato.fc.hp.com> <1409873255.28990.158.camel@misato.fc.hp.com> <20140905102347.GA30096@gmail.com> <1409925023.28990.176.camel@misato.fc.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1409925023.28990.176.camel@misato.fc.hp.com> Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: Ingo Molnar , hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com On Fri, 05 Sep 2014, Toshi Kani wrote: > On Fri, 2014-09-05 at 12:23 +0200, Ingo Molnar wrote: > > Any reason why we have to create such a sharp boundary, instead > > of simply saying: 'disable PAT on all x86 CPU families that have > > at least one buggy model'? > > > > That would nicely sort out all the broken CPUs, and would make it > > highly unlikely that we'd accidentally forget about a model or > > two. > > Agreed. I will disable this feature on all Pentium 4 models as well. I > do not think there is any necessity to enable it on Pentium 4. Thank you. That takes care of my misguivings about enabling this on aging platforms as well. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by kanga.kvack.org (Postfix) with ESMTP id C58A56B0035 for ; Sun, 7 Sep 2014 12:50:05 -0400 (EDT) Received: by mail-lb0-f171.google.com with SMTP id 10so6723001lbg.16 for ; Sun, 07 Sep 2014 09:50:04 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by mx.google.com with ESMTPS id w5si10815043lae.42.2014.09.07.09.50.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 09:50:03 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id b8so4890214lan.39 for ; Sun, 07 Sep 2014 09:50:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <540C1C01.1000308@plexistor.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> <540C1C01.1000308@plexistor.com> From: Andy Lutomirski Date: Sun, 7 Sep 2014 09:49:41 -0700 Message-ID: Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Yigal Korman Cc: Toshi Kani , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman wrote: > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt > If it's possible, can you please update pat.txt as part of the patch? Indeed. That file seems to indicate several times that the intended use of set_memory_xyz is for RAM. --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by kanga.kvack.org (Postfix) with ESMTP id 1D7E56B0036 for ; Mon, 8 Sep 2014 11:18:21 -0400 (EDT) Received: by mail-oa0-f45.google.com with SMTP id n16so10687353oag.4 for ; Mon, 08 Sep 2014 08:18:17 -0700 (PDT) Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com. [15.201.208.53]) by mx.google.com with ESMTPS id c3si14696571oex.81.2014.09.08.08.18.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Sep 2014 08:18:16 -0700 (PDT) Message-ID: <1410188863.28990.209.camel@misato.fc.hp.com> Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT From: Toshi Kani Date: Mon, 08 Sep 2014 09:07:43 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> <540C1C01.1000308@plexistor.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Yigal Korman , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk On Sun, 2014-09-07 at 09:49 -0700, Andy Lutomirski wrote: > On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman wrote: > > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt > > If it's possible, can you please update pat.txt as part of the patch? > > Indeed. That file seems to indicate several times that the intended > use of set_memory_xyz is for RAM. Good point. pat.txt is correct that the "intended" use of set_memory_xyz() is for RAM since there is no other way to set non-WB attribute for RAM. For reserved memory, one should call ioremap_xyz() to map with the xyz attribute directly. From the functionality POV, set_memory_xyz() works for reserved memory, but such usage is not intended. Should I drop the patch 4/5 until we can track the use of WT for RAM? Thanks, -Toshi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by kanga.kvack.org (Postfix) with ESMTP id B38B86B0037 for ; Mon, 8 Sep 2014 13:24:03 -0400 (EDT) Received: by mail-lb0-f178.google.com with SMTP id c11so1712300lbj.37 for ; Mon, 08 Sep 2014 10:24:02 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by mx.google.com with ESMTPS id e10si10037346lae.93.2014.09.08.10.24.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 10:24:01 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id c11so1711787lbj.23 for ; Mon, 08 Sep 2014 10:24:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1410188863.28990.209.camel@misato.fc.hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> <540C1C01.1000308@plexistor.com> <1410188863.28990.209.camel@misato.fc.hp.com> From: Andy Lutomirski Date: Mon, 8 Sep 2014 10:23:40 -0700 Message-ID: Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: "linux-mm@kvack.org" , Yigal Korman , Juergen Gross , Arnd Bergmann , Thomas Gleixner , akpm@linuxfoundation.org, Ingo Molnar , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Konrad Rzeszutek Wilk , Stefan Bader On Sep 8, 2014 8:18 AM, "Toshi Kani" wrote: > > On Sun, 2014-09-07 at 09:49 -0700, Andy Lutomirski wrote: > > On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman wrote: > > > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt > > > If it's possible, can you please update pat.txt as part of the patch? > > > > Indeed. That file seems to indicate several times that the intended > > use of set_memory_xyz is for RAM. > > > Good point. pat.txt is correct that the "intended" use of > set_memory_xyz() is for RAM since there is no other way to set non-WB > attribute for RAM. For reserved memory, one should call ioremap_xyz() > to map with the xyz attribute directly. From the functionality POV, > set_memory_xyz() works for reserved memory, but such usage is not > intended. > > Should I drop the patch 4/5 until we can track the use of WT for RAM? Probably not. I can imagine someone ioremapping a huge chunk of NV-DIMM and then wanting to change some of it to WT. Unless I've missed something (which is rather likely), the cleanest way to do this is with set_memory_wt. If that happens, someone should update pat.txt to indicate that it's allowed. --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by kanga.kvack.org (Postfix) with ESMTP id D7F766B0036 for ; Mon, 8 Sep 2014 14:52:35 -0400 (EDT) Received: by mail-oa0-f44.google.com with SMTP id o6so11025596oag.31 for ; Mon, 08 Sep 2014 11:52:35 -0700 (PDT) Received: from g4t3426.houston.hp.com (g4t3426.houston.hp.com. [15.201.208.54]) by mx.google.com with ESMTPS id ts9si8152543oeb.39.2014.09.08.11.52.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Sep 2014 11:52:35 -0700 (PDT) Message-ID: <1410201722.28990.219.camel@misato.fc.hp.com> Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT From: Toshi Kani Date: Mon, 08 Sep 2014 12:42:02 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> <540C1C01.1000308@plexistor.com> <1410188863.28990.209.camel@misato.fc.hp.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: "linux-mm@kvack.org" , Yigal Korman , Juergen Gross , Arnd Bergmann , Thomas Gleixner , akpm@linuxfoundation.org, Ingo Molnar , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Konrad Rzeszutek Wilk , Stefan Bader On Mon, 2014-09-08 at 10:23 -0700, Andy Lutomirski wrote: > On Sep 8, 2014 8:18 AM, "Toshi Kani" wrote: > > > > On Sun, 2014-09-07 at 09:49 -0700, Andy Lutomirski wrote: > > > On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman wrote: > > > > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt > > > > If it's possible, can you please update pat.txt as part of the patch? > > > > > > Indeed. That file seems to indicate several times that the intended > > > use of set_memory_xyz is for RAM. > > > > > > Good point. pat.txt is correct that the "intended" use of > > set_memory_xyz() is for RAM since there is no other way to set non-WB > > attribute for RAM. For reserved memory, one should call ioremap_xyz() > > to map with the xyz attribute directly. From the functionality POV, > > set_memory_xyz() works for reserved memory, but such usage is not > > intended. > > > > Should I drop the patch 4/5 until we can track the use of WT for RAM? > > Probably not. I can imagine someone ioremapping a huge chunk of > NV-DIMM and then wanting to change some of it to WT. Unless I've > missed something (which is rather likely), the cleanest way to do this > is with set_memory_wt. Yeah, that sounds possible. > If that happens, someone should update pat.txt to indicate that it's allowed. Since it is unlikely that someone will update pat.txt later, I will update it to: ------------------------------------------------------------------- API | RAM | ACPI,... | Reserved/Holes | -----------------------|----------|------------|------------------| set_memory_wt | *1 | -- | WT | set_memory_wb | | | | *1: -EINVAL due to the current limitation in reserve_memtype(). Thanks, -Toshi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by kanga.kvack.org (Postfix) with ESMTP id E5B7F6B0038 for ; Fri, 12 Sep 2014 15:25:24 -0400 (EDT) Received: by mail-pa0-f47.google.com with SMTP id ey11so1909400pad.20 for ; Fri, 12 Sep 2014 12:25:24 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com. [156.151.31.81]) by mx.google.com with ESMTPS id f8si9746528pdm.106.2014.09.12.12.25.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Sep 2014 12:25:23 -0700 (PDT) Date: Fri, 12 Sep 2014 15:25:01 -0400 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140912192501.GG15656@laptop.dumpdata.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Toshi Kani , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader On Thu, Sep 04, 2014 at 04:34:43PM -0700, Andy Lutomirski wrote: > On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh > wrote: > > On Thu, 04 Sep 2014, H. Peter Anvin wrote: > >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > >> > I am worried of uncharted territory, here. I'd actually advocate for not > >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > >> > is using them as well. Is this a real concern, or am I being overly > >> > cautious? > >> > >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and > >> not in 64-bit mode on the same CPU. > > > > Sure, but is it really a good idea to enable this on the *old* non-64-bit > > capable processors (note: I don't mean x86-64 processors operating in 32-bit > > mode) ? > > > >> As far as I know, the current blacklist rule is very conservative due to > >> lack of testing more than anything else. > > > > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted > > from using PAT :-) > > At the very least, anyone who plugs an NV-DIMM into a 32-bit machine > is nuts, and not just because I'd be somewhat amazed if it even > physically fits into the slot. :) They do have PCIe to PCI adapters, so you _could_ do it :-) > > --Andy > > > > > -- > > "One disk to rule them all, One disk to find them. One disk to bring > > them all and in the darkness grind them. In the Land of Redmond > > where the shadows lie." -- The Silicon Valley Tarot > > Henrique Holschuh > > > > -- > Andy Lutomirski > AMA Capital Management, LLC -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by kanga.kvack.org (Postfix) with ESMTP id 9BD3A6B0035 for ; Fri, 12 Sep 2014 16:03:35 -0400 (EDT) Received: by mail-lb0-f171.google.com with SMTP id 10so1551921lbg.2 for ; Fri, 12 Sep 2014 13:03:33 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by mx.google.com with ESMTPS id b9si8166412lbp.50.2014.09.12.13.03.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 13:03:32 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 10so1552637lbg.16 for ; Fri, 12 Sep 2014 13:03:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140912192501.GG15656@laptop.dumpdata.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <20140912192501.GG15656@laptop.dumpdata.com> From: Andy Lutomirski Date: Fri, 12 Sep 2014 13:03:12 -0700 Message-ID: Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Konrad Rzeszutek Wilk Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Toshi Kani , Thomas Gleixner , Ingo Molnar , Andrew Morton , Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader On Fri, Sep 12, 2014 at 12:25 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 04, 2014 at 04:34:43PM -0700, Andy Lutomirski wrote: >> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine >> is nuts, and not just because I'd be somewhat amazed if it even >> physically fits into the slot. :) > > They do have PCIe to PCI adapters, so you _could_ do it :-) > My NV-DIMMs are DDR3 RDIMMs, so it would be a very magical adapter indeed. --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by kanga.kvack.org (Postfix) with ESMTP id 9B2436B003A for ; Fri, 12 Sep 2014 16:21:56 -0400 (EDT) Received: by mail-pd0-f172.google.com with SMTP id v10so1978275pde.3 for ; Fri, 12 Sep 2014 13:21:56 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com. [141.146.126.69]) by mx.google.com with ESMTPS id ay7si9905914pdb.155.2014.09.12.13.21.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Sep 2014 13:21:55 -0700 (PDT) Date: Fri, 12 Sep 2014 16:21:38 -0400 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140912202138.GA24501@laptop.dumpdata.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <20140912192501.GG15656@laptop.dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Toshi Kani , Thomas Gleixner , Ingo Molnar , Andrew Morton , Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader On Fri, Sep 12, 2014 at 01:03:12PM -0700, Andy Lutomirski wrote: > On Fri, Sep 12, 2014 at 12:25 PM, Konrad Rzeszutek Wilk > wrote: > > On Thu, Sep 04, 2014 at 04:34:43PM -0700, Andy Lutomirski wrote: > >> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine > >> is nuts, and not just because I'd be somewhat amazed if it even > >> physically fits into the slot. :) > > > > They do have PCIe to PCI adapters, so you _could_ do it :-) > > > > My NV-DIMMs are DDR3 RDIMMs, so it would be a very magical adapter indeed. I misread that as 'NVME', duh! > > --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754743AbaIDSqU (ORCPT ); Thu, 4 Sep 2014 14:46:20 -0400 Received: from g9t1613g.houston.hp.com ([15.240.0.71]:46059 "EHLO g9t1613g.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751661AbaIDSqT (ORCPT ); Thu, 4 Sep 2014 14:46:19 -0400 From: Toshi Kani To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com Subject: [PATCH 0/5] Support Write-Through mapping on x86 Date: Thu, 4 Sep 2014 12:35:34 -0600 Message-Id: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> X-Mailer: git-send-email 1.8.3.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patchset adds support of Write-Through (WT) mapping on x86. The study below shows that using WT mapping may be useful for non-volatile memory. http://www.hpl.hp.com/techreports/2012/HPL-2012-236.pdf This patchset applies on top of the Juergen's patchset below, which provides the basis of the PAT management. https://lkml.org/lkml/2014/8/26/61 All new/modified interfaces have been tested. --- Toshi Kani (5): 1/5 x86, mm, pat: Set WT to PA4 slot of PAT MSR 2/5 x86, mm, pat: Change reserve_memtype() to handle WT 3/5 x86, mm, asm-gen: Add ioremap_wt() for WT 4/5 x86, mm: Add set_memory_wt() for WT 5/5 x86, mm, pat: Add pgprot_writethrough() for WT --- arch/x86/include/asm/cacheflush.h | 10 ++++- arch/x86/include/asm/io.h | 2 + arch/x86/include/asm/pgtable_types.h | 3 ++ arch/x86/mm/ioremap.c | 24 ++++++++++++ arch/x86/mm/pageattr.c | 73 +++++++++++++++++++++++++++++++++--- arch/x86/mm/pat.c | 73 +++++++++++++++++++++++++++--------- include/asm-generic/io.h | 4 ++ include/asm-generic/iomap.h | 4 ++ include/asm-generic/pgtable.h | 4 ++ 9 files changed, 172 insertions(+), 25 deletions(-) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755092AbaIDSrk (ORCPT ); Thu, 4 Sep 2014 14:47:40 -0400 Received: from g2t1383g.austin.hp.com ([15.217.136.92]:10290 "EHLO g2t1383g.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751620AbaIDSrj (ORCPT ); Thu, 4 Sep 2014 14:47:39 -0400 From: Toshi Kani To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com, Toshi Kani Subject: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Date: Thu, 4 Sep 2014 12:35:35 -0600 Message-Id: <1409855739-8985-2-git-send-email-toshi.kani@hp.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch sets WT to the PA4 slot in the PAT MSR when the processor is not affected by the PAT errata. The upper 4 slots of the PAT MSR are continued to be unused on the following Intel processors. errata cpuid -------------------------------------- Pentium 2, A52 family 0x6, model 0x5 Pentium 3, E27 family 0x6, model 0x7 Pentium M, Y26 family 0x6, model 0x9 Pentium 4, N46 family 0xf, model 0x0 For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- per the default setup in __cachemode2pte_tbl[]. Signed-off-by: Toshi Kani --- arch/x86/mm/pat.c | 47 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 15 deletions(-) diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c index feb4d30..b1891dc 100644 --- a/arch/x86/mm/pat.c +++ b/arch/x86/mm/pat.c @@ -132,6 +132,7 @@ void pat_init(void) { u64 pat; bool boot_cpu = !boot_pat_state; + struct cpuinfo_x86 *c = &boot_cpu_data; if (!pat_enabled) return; @@ -152,21 +153,37 @@ void pat_init(void) } } - /* Set PWT to Write-Combining. All other bits stay the same */ - /* - * PTE encoding used in Linux: - * PAT - * |PCD - * ||PWT - * ||| - * 000 WB _PAGE_CACHE_WB - * 001 WC _PAGE_CACHE_WC - * 010 UC- _PAGE_CACHE_UC_MINUS - * 011 UC _PAGE_CACHE_UC - * PAT bit unused - */ - pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) | - PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC); + if ((c->x86_vendor == X86_VENDOR_INTEL) && + (((c->x86 == 0x6) && + ((c->x86_model == 0x5) || + (c->x86_model == 0x7) || + (c->x86_model == 0x9))) || + ((c->x86 == 0xf) && (c->x86_model == 0x0)))) { + /* + * Upper four PAT entries are not usable on the following + * Intel processors. + * + * errata cpuid + * -------------------------------------- + * Pentium 2, A52 family 0x6, model 0x5 + * Pentium 3, E27 family 0x6, model 0x7 + * Pentium M, Y26 family 0x6, model 0x9 + * Pentium 4, N46 family 0xf, model 0x0 + * + * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4-7:unusable + * + * NOTE: When WT or WP is used, it is redirected * to UC- + * per the default setup in __cachemode2pte_tbl[]. + */ + pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) | + PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC); + } else { + /* + * PAT 0:WB, 1:WC, 2:UC-, 3:UC, 4:WT, 5-7:reserved + */ + pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) | + PAT(4, WT) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC); + } /* Boot CPU check */ if (!boot_pat_state) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755182AbaIDSrx (ORCPT ); Thu, 4 Sep 2014 14:47:53 -0400 Received: from g2t1383g.austin.hp.com ([15.217.136.92]:10301 "EHLO g2t1383g.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755131AbaIDSrw (ORCPT ); Thu, 4 Sep 2014 14:47:52 -0400 From: Toshi Kani To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com, Toshi Kani Subject: [PATCH 3/5] x86, mm, asm-gen: Add ioremap_wt() for WT Date: Thu, 4 Sep 2014 12:35:37 -0600 Message-Id: <1409855739-8985-4-git-send-email-toshi.kani@hp.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch adds ioremap_wt() for creating WT mapping on x86. It follows the same model as ioremap_wc() for multi-architecture support. ARCH_HAS_IOREMAP_WT is defined in the x86 version of io.h to indicate that ioremap_wt() is implemented on x86. Signed-off-by: Toshi Kani --- arch/x86/include/asm/io.h | 2 ++ arch/x86/mm/ioremap.c | 24 ++++++++++++++++++++++++ include/asm-generic/io.h | 4 ++++ include/asm-generic/iomap.h | 4 ++++ 4 files changed, 34 insertions(+) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 71b9e65..c813c86 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -35,6 +35,7 @@ */ #define ARCH_HAS_IOREMAP_WC +#define ARCH_HAS_IOREMAP_WT #include #include @@ -316,6 +317,7 @@ extern void unxlate_dev_mem_ptr(unsigned long phys, void *addr); extern int ioremap_change_attr(unsigned long vaddr, unsigned long size, enum page_cache_mode pcm); extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size); +extern void __iomem *ioremap_wt(resource_size_t offset, unsigned long size); extern bool is_early_ioremap_ptep(pte_t *ptep); diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 885fe44..952f4b4 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -155,6 +155,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr, prot = __pgprot(pgprot_val(prot) | cachemode2protval(_PAGE_CACHE_MODE_WC)); break; + case _PAGE_CACHE_MODE_WT: + prot = __pgprot(pgprot_val(prot) | + cachemode2protval(_PAGE_CACHE_MODE_WT)); + break; case _PAGE_CACHE_MODE_WB: break; } @@ -249,6 +253,26 @@ void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size) } EXPORT_SYMBOL(ioremap_wc); +/** + * ioremap_wt - map memory into CPU space write through + * @phys_addr: bus address of the memory + * @size: size of the resource to map + * + * This version of ioremap ensures that the memory is marked write through. + * Write through writes data into memory while keeping the cache up-to-date. + * + * Must be freed with iounmap. + */ +void __iomem *ioremap_wt(resource_size_t phys_addr, unsigned long size) +{ + if (pat_enabled) + return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WT, + __builtin_return_address(0)); + else + return ioremap_nocache(phys_addr, size); +} +EXPORT_SYMBOL(ioremap_wt); + void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size) { return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB, diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index 975e1cc..405d418 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -322,6 +322,10 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size) #define ioremap_wc ioremap_nocache #endif +#ifndef ioremap_wt +#define ioremap_wt ioremap_nocache +#endif + static inline void iounmap(void __iomem *addr) { } diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h index 1b41011..d8f8622 100644 --- a/include/asm-generic/iomap.h +++ b/include/asm-generic/iomap.h @@ -66,6 +66,10 @@ extern void ioport_unmap(void __iomem *); #define ioremap_wc ioremap_nocache #endif +#ifndef ARCH_HAS_IOREMAP_WT +#define ioremap_wt ioremap_nocache +#endif + #ifdef CONFIG_PCI /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev; From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755226AbaIDSsw (ORCPT ); Thu, 4 Sep 2014 14:48:52 -0400 Received: from g9t1613g.houston.hp.com ([15.240.0.71]:46648 "EHLO g9t1613g.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754963AbaIDSst (ORCPT ); Thu, 4 Sep 2014 14:48:49 -0400 From: Toshi Kani To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com, Toshi Kani Subject: [PATCH 2/5] x86, mm, pat: Change reserve_memtype() to handle WT Date: Thu, 4 Sep 2014 12:35:36 -0600 Message-Id: <1409855739-8985-3-git-send-email-toshi.kani@hp.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch changes reserve_memtype() to handle the WT cache mode. When PAT is not enabled, it continues to set UC- to *new_type for any non-WB request. When a target range is RAM, reserve_ram_pages_type() fails for WT for now. This function may not reserve a RAM range for WT since reserve_ram_pages_type() uses the page flags limited to three memory types, WB, WC and UC. Signed-off-by: Toshi Kani --- arch/x86/include/asm/cacheflush.h | 4 ++++ arch/x86/mm/pat.c | 16 +++++++++++++--- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h index 157644b..c912680 100644 --- a/arch/x86/include/asm/cacheflush.h +++ b/arch/x86/include/asm/cacheflush.h @@ -53,6 +53,10 @@ static inline void set_page_memtype(struct page *pg, case _PAGE_CACHE_MODE_WB: memtype_flags = _PGMT_WB; break; + case _PAGE_CACHE_MODE_WT: + case _PAGE_CACHE_MODE_WP: + pr_err("set_page_memtype: unsupported cachemode %d\n", memtype); + BUG(); default: memtype_flags = _PGMT_DEFAULT; break; diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c index b1891dc..87b21dd 100644 --- a/arch/x86/mm/pat.c +++ b/arch/x86/mm/pat.c @@ -271,6 +271,8 @@ static int pat_pagerange_is_ram(resource_size_t start, resource_size_t end) /* * For RAM pages, we use page flags to mark the pages with appropriate type. + * The page flags are currently limited to three types, WB, WC and UC. Hence, + * any request to WT or WP will fail with -EINVAL. * Here we do two pass: * - Find the memtype of all the pages in the range, look for any conflicts * - In case of no conflicts, set the new memtype for pages in the range @@ -282,6 +284,13 @@ static int reserve_ram_pages_type(u64 start, u64 end, struct page *page; u64 pfn; + if ((req_type == _PAGE_CACHE_MODE_WT) || + (req_type == _PAGE_CACHE_MODE_WP)) { + if (new_type) + *new_type = _PAGE_CACHE_MODE_UC_MINUS; + return -EINVAL; + } + if (req_type == _PAGE_CACHE_MODE_UC) { /* We do not support strong UC */ WARN_ON_ONCE(1); @@ -331,6 +340,7 @@ static int free_ram_pages_type(u64 start, u64 end) * - _PAGE_CACHE_MODE_WC * - _PAGE_CACHE_MODE_UC_MINUS * - _PAGE_CACHE_MODE_UC + * - _PAGE_CACHE_MODE_WT * * If new_type is NULL, function will return an error if it cannot reserve the * region with req_type. If new_type is non-NULL, function will return @@ -350,10 +360,10 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type, if (!pat_enabled) { /* This is identical to page table setting without PAT */ if (new_type) { - if (req_type == _PAGE_CACHE_MODE_WC) - *new_type = _PAGE_CACHE_MODE_UC_MINUS; + if (req_type == _PAGE_CACHE_MODE_WB) + *new_type = _PAGE_CACHE_MODE_WB; else - *new_type = req_type; + *new_type = _PAGE_CACHE_MODE_UC_MINUS; } return 0; } From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755245AbaIDStA (ORCPT ); Thu, 4 Sep 2014 14:49:00 -0400 Received: from g2t1383g.austin.hp.com ([15.217.136.92]:10886 "EHLO g2t1383g.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754963AbaIDSs6 (ORCPT ); Thu, 4 Sep 2014 14:48:58 -0400 From: Toshi Kani To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com, Toshi Kani Subject: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT Date: Thu, 4 Sep 2014 12:35:38 -0600 Message-Id: <1409855739-8985-5-git-send-email-toshi.kani@hp.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch adds set_memory_wt(), set_memory_array_wt(), and set_pages_array_wt() for setting range(s) of memory to WT. Note that reserve_memtype() only supports WT for non-RAM ranges at this point. Signed-off-by: Toshi Kani --- arch/x86/include/asm/cacheflush.h | 6 +++ arch/x86/mm/pageattr.c | 73 ++++++++++++++++++++++++++++++++++--- 2 files changed, 72 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h index c912680..5bfd5d0 100644 --- a/arch/x86/include/asm/cacheflush.h +++ b/arch/x86/include/asm/cacheflush.h @@ -81,7 +81,7 @@ static inline void set_page_memtype(struct page *pg, /* * The set_memory_* API can be used to change various attributes of a virtual * address range. The attributes include: - * Cachability : UnCached, WriteCombining, WriteBack + * Cachability : UnCached, WriteCombining, WriteThrough, WriteBack * Executability : eXeutable, NoteXecutable * Read/Write : ReadOnly, ReadWrite * Presence : NotPresent @@ -108,9 +108,11 @@ static inline void set_page_memtype(struct page *pg, int _set_memory_uc(unsigned long addr, int numpages); int _set_memory_wc(unsigned long addr, int numpages); +int _set_memory_wt(unsigned long addr, int numpages); int _set_memory_wb(unsigned long addr, int numpages); int set_memory_uc(unsigned long addr, int numpages); int set_memory_wc(unsigned long addr, int numpages); +int set_memory_wt(unsigned long addr, int numpages); int set_memory_wb(unsigned long addr, int numpages); int set_memory_x(unsigned long addr, int numpages); int set_memory_nx(unsigned long addr, int numpages); @@ -121,10 +123,12 @@ int set_memory_4k(unsigned long addr, int numpages); int set_memory_array_uc(unsigned long *addr, int addrinarray); int set_memory_array_wc(unsigned long *addr, int addrinarray); +int set_memory_array_wt(unsigned long *addr, int addrinarray); int set_memory_array_wb(unsigned long *addr, int addrinarray); int set_pages_array_uc(struct page **pages, int addrinarray); int set_pages_array_wc(struct page **pages, int addrinarray); +int set_pages_array_wt(struct page **pages, int addrinarray); int set_pages_array_wb(struct page **pages, int addrinarray); /* diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 6917b39..2dda151 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -1484,12 +1484,10 @@ EXPORT_SYMBOL(set_memory_uc); static int _set_memory_array(unsigned long *addr, int addrinarray, enum page_cache_mode new_type) { + enum page_cache_mode set_type; int i, j; int ret; - /* - * for now UC MINUS. see comments in ioremap_nocache() - */ for (i = 0; i < addrinarray; i++) { ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE, new_type, NULL); @@ -1497,9 +1495,12 @@ static int _set_memory_array(unsigned long *addr, int addrinarray, goto out_free; } + /* If WC, set to UC- first and then WC */ + set_type = (new_type == _PAGE_CACHE_MODE_WC) ? + _PAGE_CACHE_MODE_UC_MINUS : new_type; + ret = change_page_attr_set(addr, addrinarray, - cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS), - 1); + cachemode2pgprot(set_type), 1); if (!ret && new_type == _PAGE_CACHE_MODE_WC) ret = change_page_attr_set_clr(addr, addrinarray, @@ -1527,10 +1528,22 @@ EXPORT_SYMBOL(set_memory_array_uc); int set_memory_array_wc(unsigned long *addr, int addrinarray) { + if (!pat_enabled) + return set_memory_array_uc(addr, addrinarray); + return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WC); } EXPORT_SYMBOL(set_memory_array_wc); +int set_memory_array_wt(unsigned long *addr, int addrinarray) +{ + if (!pat_enabled) + return set_memory_array_uc(addr, addrinarray); + + return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WT); +} +EXPORT_SYMBOL(set_memory_array_wt); + int _set_memory_wc(unsigned long addr, int numpages) { int ret; @@ -1574,6 +1587,37 @@ out_err: } EXPORT_SYMBOL(set_memory_wc); +int _set_memory_wt(unsigned long addr, int numpages) +{ + return change_page_attr_set(&addr, numpages, + cachemode2pgprot(_PAGE_CACHE_MODE_WT), 0); +} + +int set_memory_wt(unsigned long addr, int numpages) +{ + int ret; + + if (!pat_enabled) + return set_memory_uc(addr, numpages); + + ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE, + _PAGE_CACHE_MODE_WT, NULL); + if (ret) + goto out_err; + + ret = _set_memory_wt(addr, numpages); + if (ret) + goto out_free; + + return 0; + +out_free: + free_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE); +out_err: + return ret; +} +EXPORT_SYMBOL(set_memory_wt); + int _set_memory_wb(unsigned long addr, int numpages) { /* WB cache mode is hard wired to all cache attribute bits being 0 */ @@ -1666,6 +1710,7 @@ static int _set_pages_array(struct page **pages, int addrinarray, { unsigned long start; unsigned long end; + enum page_cache_mode set_type; int i; int free_idx; int ret; @@ -1679,8 +1724,12 @@ static int _set_pages_array(struct page **pages, int addrinarray, goto err_out; } + /* If WC, set to UC- first and then WC */ + set_type = (new_type == _PAGE_CACHE_MODE_WC) ? + _PAGE_CACHE_MODE_UC_MINUS : new_type; + ret = cpa_set_pages_array(pages, addrinarray, - cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS)); + cachemode2pgprot(set_type)); if (!ret && new_type == _PAGE_CACHE_MODE_WC) ret = change_page_attr_set_clr(NULL, addrinarray, cachemode2pgprot( @@ -1710,10 +1759,22 @@ EXPORT_SYMBOL(set_pages_array_uc); int set_pages_array_wc(struct page **pages, int addrinarray) { + if (!pat_enabled) + return set_pages_array_uc(pages, addrinarray); + return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WC); } EXPORT_SYMBOL(set_pages_array_wc); +int set_pages_array_wt(struct page **pages, int addrinarray) +{ + if (!pat_enabled) + return set_pages_array_uc(pages, addrinarray); + + return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WT); +} +EXPORT_SYMBOL(set_pages_array_wt); + int set_pages_wb(struct page *page, int numpages) { unsigned long addr = (unsigned long)page_address(page); From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755207AbaIDSsv (ORCPT ); Thu, 4 Sep 2014 14:48:51 -0400 Received: from g9t1613g.houston.hp.com ([15.240.0.71]:46647 "EHLO g9t1613g.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755074AbaIDSst (ORCPT ); Thu, 4 Sep 2014 14:48:49 -0400 From: Toshi Kani To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com, Toshi Kani Subject: [PATCH 5/5] x86, mm, pat: Add pgprot_writethrough() for WT Date: Thu, 4 Sep 2014 12:35:39 -0600 Message-Id: <1409855739-8985-6-git-send-email-toshi.kani@hp.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch adds pgprot_writethrough() for setting WT to a given pgprot_t. Signed-off-by: Toshi Kani --- arch/x86/include/asm/pgtable_types.h | 3 +++ arch/x86/mm/pat.c | 10 ++++++++++ include/asm-generic/pgtable.h | 4 ++++ 3 files changed, 17 insertions(+) diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index bd2f50f..cc7c65d 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -394,6 +394,9 @@ extern int nx_enabled; #define pgprot_writecombine pgprot_writecombine extern pgprot_t pgprot_writecombine(pgprot_t prot); +#define pgprot_writethrough pgprot_writethrough +extern pgprot_t pgprot_writethrough(pgprot_t prot); + /* Indicate that x86 has its own track and untrack pfn vma functions */ #define __HAVE_PFNMAP_TRACKING diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c index 87b21dd..ed62ead 100644 --- a/arch/x86/mm/pat.c +++ b/arch/x86/mm/pat.c @@ -878,6 +878,16 @@ pgprot_t pgprot_writecombine(pgprot_t prot) } EXPORT_SYMBOL_GPL(pgprot_writecombine); +pgprot_t pgprot_writethrough(pgprot_t prot) +{ + if (pat_enabled) + return __pgprot(pgprot_val(prot) | + cachemode2protval(_PAGE_CACHE_MODE_WT)); + else + return pgprot_noncached(prot); +} +EXPORT_SYMBOL_GPL(pgprot_writethrough); + #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT) static struct memtype *memtype_get_idx(loff_t pos) diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index 53b2acc..1af0ed9 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b) #define pgprot_writecombine pgprot_noncached #endif +#ifndef pgprot_writethrough +#define pgprot_writethrough pgprot_noncached +#endif + /* * When walking page tables, get the address of the next boundary, * or the end address of the range if that comes earlier. Although no From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755140AbaIDS5Y (ORCPT ); Thu, 4 Sep 2014 14:57:24 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:53429 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755085AbaIDS5X (ORCPT ); Thu, 4 Sep 2014 14:57:23 -0400 MIME-Version: 1.0 In-Reply-To: <1409855739-8985-5-git-send-email-toshi.kani@hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> From: Andy Lutomirski Date: Thu, 4 Sep 2014 11:57:01 -0700 Message-ID: Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT To: Toshi Kani Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani wrote: > This patch adds set_memory_wt(), set_memory_array_wt(), and > set_pages_array_wt() for setting range(s) of memory to WT. > Possibly dumb question: I thought that set_memory_xyz was only for RAM. Is that incorrect? --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755281AbaIDTHh (ORCPT ); Thu, 4 Sep 2014 15:07:37 -0400 Received: from g6t1526.atlanta.hp.com ([15.193.200.69]:42347 "EHLO g6t1526.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755058AbaIDTHf (ORCPT ); Thu, 4 Sep 2014 15:07:35 -0400 X-Greylist: delayed 1201 seconds by postgrey-1.27 at vger.kernel.org; Thu, 04 Sep 2014 15:07:35 EDT Message-ID: <1409857025.28990.125.camel@misato.fc.hp.com> Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT From: Toshi Kani To: Andy Lutomirski Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Date: Thu, 04 Sep 2014 12:57:05 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote: > On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani wrote: > > This patch adds set_memory_wt(), set_memory_array_wt(), and > > set_pages_array_wt() for setting range(s) of memory to WT. > > > > Possibly dumb question: I thought that set_memory_xyz was only for > RAM. Is that incorrect? It works for non-RAM ranges as well. For instance, you can use set_memory_xyz() to change cache attribute for a non-RAM range mapped by ioremap_cache(). Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755290AbaIDTPR (ORCPT ); Thu, 4 Sep 2014 15:15:17 -0400 Received: from mail-la0-f49.google.com ([209.85.215.49]:56102 "EHLO mail-la0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755104AbaIDTPP (ORCPT ); Thu, 4 Sep 2014 15:15:15 -0400 MIME-Version: 1.0 In-Reply-To: <1409857025.28990.125.camel@misato.fc.hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> From: Andy Lutomirski Date: Thu, 4 Sep 2014 12:14:54 -0700 Message-ID: Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT To: Toshi Kani Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 4, 2014 at 11:57 AM, Toshi Kani wrote: > On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote: >> On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani wrote: >> > This patch adds set_memory_wt(), set_memory_array_wt(), and >> > set_pages_array_wt() for setting range(s) of memory to WT. >> > >> >> Possibly dumb question: I thought that set_memory_xyz was only for >> RAM. Is that incorrect? > > It works for non-RAM ranges as well. For instance, you can use > set_memory_xyz() to change cache attribute for a non-RAM range mapped by > ioremap_cache(). OK -- I didn't realize that was legal. Do you, by any chance, have a test driver for this? For example, something that lets your reserve some WT memory at boot and mmap it? I wouldn't mind getting some benchmarks, and I can even throw it at the NV-DIMM box that's sitting under my desk :) --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755370AbaIDULh (ORCPT ); Thu, 4 Sep 2014 16:11:37 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:56330 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755210AbaIDULg (ORCPT ); Thu, 4 Sep 2014 16:11:36 -0400 X-Sasl-enc: xdeHoSPDlQxACp8TGUe5y6cP1WLHB30gdok5lINHsUVP 1409861495 Date: Thu, 4 Sep 2014 17:11:23 -0300 From: Henrique de Moraes Holschuh To: Toshi Kani Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140904201123.GA9116@khazad-dum.debian.net> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1409855739-8985-2-git-send-email-toshi.kani@hp.com> X-GPG-Fingerprint1: 4096R/39CB4807 C467 A717 507B BAFE D3C1 6092 0BD9 E811 39CB 4807 X-GPG-Fingerprint2: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 04 Sep 2014, Toshi Kani wrote: > This patch sets WT to the PA4 slot in the PAT MSR when the processor > is not affected by the PAT errata. The upper 4 slots of the PAT MSR > are continued to be unused on the following Intel processors. > > errata cpuid > -------------------------------------- > Pentium 2, A52 family 0x6, model 0x5 > Pentium 3, E27 family 0x6, model 0x7 > Pentium M, Y26 family 0x6, model 0x9 > Pentium 4, N46 family 0xf, model 0x0 > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- > per the default setup in __cachemode2pte_tbl[]. There are at least two PAT errata. The blacklist is in arch/x86/kernel/cpu/intel.c: if (c->x86 == 6 && c->x86_model < 15) clear_cpu_cap(c, X86_FEATURE_PAT); It covers model 13, which is not in your blacklist. It *is* possible that PAT would work on model 13, as I don't think it has any PAT errata listed and it was blacklisted "just in case" (from memory. I did not re-check), but this is untested, and unwise to enable on an aging platform. I am worried of uncharted territory, here. I'd actually advocate for not enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP is using them as well. Is this a real concern, or am I being overly cautious? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755369AbaIDUWU (ORCPT ); Thu, 4 Sep 2014 16:22:20 -0400 Received: from terminus.zytor.com ([198.137.202.10]:37905 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755202AbaIDUWT (ORCPT ); Thu, 4 Sep 2014 16:22:19 -0400 Message-ID: <5408C9C4.1010705@zytor.com> Date: Thu, 04 Sep 2014 13:21:24 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Henrique de Moraes Holschuh , Toshi Kani CC: tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> In-Reply-To: <20140904201123.GA9116@khazad-dum.debian.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > > I am worried of uncharted territory, here. I'd actually advocate for not > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > is using them as well. Is this a real concern, or am I being overly > cautious? > It is extremely unlikely that we'd have PAT issues in 32-bit mode and not in 64-bit mode on the same CPU. As far as I know, the current blacklist rule is very conservative due to lack of testing more than anything else. -hpa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755496AbaIDUmS (ORCPT ); Thu, 4 Sep 2014 16:42:18 -0400 Received: from g4t3425.houston.hp.com ([15.201.208.53]:28789 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751960AbaIDUmR (ORCPT ); Thu, 4 Sep 2014 16:42:17 -0400 Message-ID: <1409862708.28990.141.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani To: Henrique de Moraes Holschuh Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com Date: Thu, 04 Sep 2014 14:31:48 -0600 In-Reply-To: <20140904201123.GA9116@khazad-dum.debian.net> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote: > On Thu, 04 Sep 2014, Toshi Kani wrote: > > This patch sets WT to the PA4 slot in the PAT MSR when the processor > > is not affected by the PAT errata. The upper 4 slots of the PAT MSR > > are continued to be unused on the following Intel processors. > > > > errata cpuid > > -------------------------------------- > > Pentium 2, A52 family 0x6, model 0x5 > > Pentium 3, E27 family 0x6, model 0x7 > > Pentium M, Y26 family 0x6, model 0x9 > > Pentium 4, N46 family 0xf, model 0x0 > > > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- > > per the default setup in __cachemode2pte_tbl[]. > > There are at least two PAT errata. The blacklist is in > arch/x86/kernel/cpu/intel.c: > > if (c->x86 == 6 && c->x86_model < 15) > clear_cpu_cap(c, X86_FEATURE_PAT); > > It covers model 13, which is not in your blacklist. > > It *is* possible that PAT would work on model 13, as I don't think it has > any PAT errata listed and it was blacklisted "just in case" (from memory. I > did not re-check), but this is untested, and unwise to enable on an aging > platform. > > I am worried of uncharted territory, here. I'd actually advocate for not > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > is using them as well. Is this a real concern, or am I being overly > cautious? The blacklist you pointed out covers a different PAT errata, and is still effective after this change. pat_init() will call pat_disable() and the PAT will continue to be disabled on these processors. There is no change for them. My blacklist covers the PAT errata that makes the upper four bit unusable when the PAT is enabled. Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755373AbaIDUuk (ORCPT ); Thu, 4 Sep 2014 16:50:40 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:51417 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755256AbaIDUui (ORCPT ); Thu, 4 Sep 2014 16:50:38 -0400 MIME-Version: 1.0 In-Reply-To: <1409862708.28990.141.camel@misato.fc.hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <1409862708.28990.141.camel@misato.fc.hp.com> From: Andy Lutomirski Date: Thu, 4 Sep 2014 13:50:16 -0700 Message-ID: Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR To: Toshi Kani Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 4, 2014 at 1:31 PM, Toshi Kani wrote: > On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote: >> On Thu, 04 Sep 2014, Toshi Kani wrote: >> > This patch sets WT to the PA4 slot in the PAT MSR when the processor >> > is not affected by the PAT errata. The upper 4 slots of the PAT MSR >> > are continued to be unused on the following Intel processors. >> > >> > errata cpuid >> > -------------------------------------- >> > Pentium 2, A52 family 0x6, model 0x5 >> > Pentium 3, E27 family 0x6, model 0x7 >> > Pentium M, Y26 family 0x6, model 0x9 >> > Pentium 4, N46 family 0xf, model 0x0 >> > >> > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- >> > per the default setup in __cachemode2pte_tbl[]. >> >> There are at least two PAT errata. The blacklist is in >> arch/x86/kernel/cpu/intel.c: >> >> if (c->x86 == 6 && c->x86_model < 15) >> clear_cpu_cap(c, X86_FEATURE_PAT); >> >> It covers model 13, which is not in your blacklist. >> >> It *is* possible that PAT would work on model 13, as I don't think it has >> any PAT errata listed and it was blacklisted "just in case" (from memory. I >> did not re-check), but this is untested, and unwise to enable on an aging >> platform. >> >> I am worried of uncharted territory, here. I'd actually advocate for not >> enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP >> is using them as well. Is this a real concern, or am I being overly >> cautious? > > The blacklist you pointed out covers a different PAT errata, and is > still effective after this change. pat_init() will call pat_disable() > and the PAT will continue to be disabled on these processors. There is > no change for them. > > My blacklist covers the PAT errata that makes the upper four bit > unusable when the PAT is enabled. > IIRC a lot of the errata only matter if we try to use various PAT bits in intermediate page table entries to change the caching mode of, say, the PTE pages. If we're doing that, something's very wrong, errata or otherwise. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754601AbaIDXTi (ORCPT ); Thu, 4 Sep 2014 19:19:38 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:49464 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751272AbaIDXTg (ORCPT ); Thu, 4 Sep 2014 19:19:36 -0400 X-Sasl-enc: NNSnaCmmZzwMuM1Ij/oUwLsOYVTEy4ZXcT/k0pwY/ZKj 1409872775 Date: Thu, 4 Sep 2014 20:19:23 -0300 From: Henrique de Moraes Holschuh To: "H. Peter Anvin" Cc: Toshi Kani , tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140904231923.GA15320@khazad-dum.debian.net> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5408C9C4.1010705@zytor.com> X-GPG-Fingerprint1: 4096R/39CB4807 C467 A717 507B BAFE D3C1 6092 0BD9 E811 39CB 4807 X-GPG-Fingerprint2: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 04 Sep 2014, H. Peter Anvin wrote: > On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > > I am worried of uncharted territory, here. I'd actually advocate for not > > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > > is using them as well. Is this a real concern, or am I being overly > > cautious? > > It is extremely unlikely that we'd have PAT issues in 32-bit mode and > not in 64-bit mode on the same CPU. Sure, but is it really a good idea to enable this on the *old* non-64-bit capable processors (note: I don't mean x86-64 processors operating in 32-bit mode) ? > As far as I know, the current blacklist rule is very conservative due to > lack of testing more than anything else. I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted from using PAT :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754626AbaIDXfI (ORCPT ); Thu, 4 Sep 2014 19:35:08 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:42765 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750725AbaIDXfG (ORCPT ); Thu, 4 Sep 2014 19:35:06 -0400 MIME-Version: 1.0 In-Reply-To: <20140904231923.GA15320@khazad-dum.debian.net> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> From: Andy Lutomirski Date: Thu, 4 Sep 2014 16:34:43 -0700 Message-ID: Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR To: Henrique de Moraes Holschuh Cc: "H. Peter Anvin" , Toshi Kani , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh wrote: > On Thu, 04 Sep 2014, H. Peter Anvin wrote: >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: >> > I am worried of uncharted territory, here. I'd actually advocate for not >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP >> > is using them as well. Is this a real concern, or am I being overly >> > cautious? >> >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and >> not in 64-bit mode on the same CPU. > > Sure, but is it really a good idea to enable this on the *old* non-64-bit > capable processors (note: I don't mean x86-64 processors operating in 32-bit > mode) ? > >> As far as I know, the current blacklist rule is very conservative due to >> lack of testing more than anything else. > > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted > from using PAT :-) At the very least, anyone who plugs an NV-DIMM into a 32-bit machine is nuts, and not just because I'd be somewhat amazed if it even physically fits into the slot. :) --Andy > > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh -- Andy Lutomirski AMA Capital Management, LLC From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755423AbaIDXiI (ORCPT ); Thu, 4 Sep 2014 19:38:08 -0400 Received: from g5t1626.atlanta.hp.com ([15.192.137.9]:60255 "EHLO g5t1626.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754148AbaIDXiG (ORCPT ); Thu, 4 Sep 2014 19:38:06 -0400 X-Greylist: delayed 17517 seconds by postgrey-1.27 at vger.kernel.org; Thu, 04 Sep 2014 19:38:06 EDT Message-ID: <1409873255.28990.158.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani To: Henrique de Moraes Holschuh Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com Date: Thu, 04 Sep 2014 17:27:35 -0600 In-Reply-To: <1409862708.28990.141.camel@misato.fc.hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <1409862708.28990.141.camel@misato.fc.hp.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2014-09-04 at 14:31 -0600, Toshi Kani wrote: > On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote: > > On Thu, 04 Sep 2014, Toshi Kani wrote: > > > This patch sets WT to the PA4 slot in the PAT MSR when the processor > > > is not affected by the PAT errata. The upper 4 slots of the PAT MSR > > > are continued to be unused on the following Intel processors. > > > > > > errata cpuid > > > -------------------------------------- > > > Pentium 2, A52 family 0x6, model 0x5 > > > Pentium 3, E27 family 0x6, model 0x7 > > > Pentium M, Y26 family 0x6, model 0x9 > > > Pentium 4, N46 family 0xf, model 0x0 > > > > > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- > > > per the default setup in __cachemode2pte_tbl[]. > > > > There are at least two PAT errata. The blacklist is in > > arch/x86/kernel/cpu/intel.c: > > > > if (c->x86 == 6 && c->x86_model < 15) > > clear_cpu_cap(c, X86_FEATURE_PAT); > > > > It covers model 13, which is not in your blacklist. > > > > It *is* possible that PAT would work on model 13, as I don't think it has > > any PAT errata listed and it was blacklisted "just in case" (from memory. I > > did not re-check), but this is untested, and unwise to enable on an aging > > platform. > > > > I am worried of uncharted territory, here. I'd actually advocate for not > > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > > is using them as well. Is this a real concern, or am I being overly > > cautious? > > The blacklist you pointed out covers a different PAT errata, and is > still effective after this change. pat_init() will call pat_disable() > and the PAT will continue to be disabled on these processors. There is > no change for them. > > My blacklist covers the PAT errata that makes the upper four bit > unusable when the PAT is enabled. I checked more carefully, and it turns out that the processors that have the WC bug with PAT/MTRR also have the upper four bit bug in PAT as well. The updated blacklist is: errata cpuid -------------------------------------- Pentium 2, A52 family 0x6, model 0x5 Pentium 3, E27 family 0x6, model 0x7, 0x8 Pentium 3 Xeon, G26 family 0x6, model 0x7, 0x8, 0xa Pentium M, Y26 family 0x6, model 0x9 Pentium M 90nm, X9 family 0x6, model 0xd Pentium 4, N46 family 0xf, model 0x0 So, the check can be the same as cpu/intel.c, except that early Pentium 4 steppings also have the upper four bit bug. I will update the check. In any case, this check is only meaningful for P4 since the PAT is disabled for P2/3/M. Thanks Henrique for pointing this out! -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755579AbaIEAkW (ORCPT ); Thu, 4 Sep 2014 20:40:22 -0400 Received: from g4t3426.houston.hp.com ([15.201.208.54]:37957 "EHLO g4t3426.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751272AbaIEAkV (ORCPT ); Thu, 4 Sep 2014 20:40:21 -0400 Message-ID: <1409876991.28990.172.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani To: Andy Lutomirski Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Date: Thu, 04 Sep 2014 18:29:51 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2014-09-04 at 16:34 -0700, Andy Lutomirski wrote: > On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh > wrote: > > On Thu, 04 Sep 2014, H. Peter Anvin wrote: > >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > >> > I am worried of uncharted territory, here. I'd actually advocate for not > >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > >> > is using them as well. Is this a real concern, or am I being overly > >> > cautious? > >> > >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and > >> not in 64-bit mode on the same CPU. > > > > Sure, but is it really a good idea to enable this on the *old* non-64-bit > > capable processors (note: I don't mean x86-64 processors operating in 32-bit > > mode) ? > > > >> As far as I know, the current blacklist rule is very conservative due to > >> lack of testing more than anything else. > > > > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted > > from using PAT :-) > > At the very least, anyone who plugs an NV-DIMM into a 32-bit machine > is nuts, and not just because I'd be somewhat amazed if it even > physically fits into the slot. :) According to the spec, the upper four entries bug was fixed in Pentium 4 model 0x1. So, the remaining Intel 32-bit processors that may enable the upper four entries are Pentium 4 model 0x1-4. Should we disable it for all Pentium 4 models? Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755453AbaIEAwS (ORCPT ); Thu, 4 Sep 2014 20:52:18 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:34130 "EHLO mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751380AbaIEAwR (ORCPT ); Thu, 4 Sep 2014 20:52:17 -0400 MIME-Version: 1.0 In-Reply-To: <1409876991.28990.172.camel@misato.fc.hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> From: Andy Lutomirski Date: Thu, 4 Sep 2014 17:51:55 -0700 Message-ID: Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR To: Toshi Kani Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 4, 2014 at 5:29 PM, Toshi Kani wrote: > On Thu, 2014-09-04 at 16:34 -0700, Andy Lutomirski wrote: >> On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh >> wrote: >> > On Thu, 04 Sep 2014, H. Peter Anvin wrote: >> >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: >> >> > I am worried of uncharted territory, here. I'd actually advocate for not >> >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP >> >> > is using them as well. Is this a real concern, or am I being overly >> >> > cautious? >> >> >> >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and >> >> not in 64-bit mode on the same CPU. >> > >> > Sure, but is it really a good idea to enable this on the *old* non-64-bit >> > capable processors (note: I don't mean x86-64 processors operating in 32-bit >> > mode) ? >> > >> >> As far as I know, the current blacklist rule is very conservative due to >> >> lack of testing more than anything else. >> > >> > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted >> > from using PAT :-) >> >> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine >> is nuts, and not just because I'd be somewhat amazed if it even >> physically fits into the slot. :) > > According to the spec, the upper four entries bug was fixed in Pentium 4 > model 0x1. So, the remaining Intel 32-bit processors that may enable > the upper four entries are Pentium 4 model 0x1-4. Should we disable it > for all Pentium 4 models? Assuming that this is Pentium 4 erratum N46, then there may be another option: use slot 7 instead of slot 4 for WT. Then, even if somehow the blacklist screws up, the worst that happens is that a WT page gets interpreted as UC. I suppose this could cause aliasing issues, but can't cause problems for people who don't use the high entries in the first place. --Andy > > Thanks, > -Toshi > -- Andy Lutomirski AMA Capital Management, LLC From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932139AbaIEKXy (ORCPT ); Fri, 5 Sep 2014 06:23:54 -0400 Received: from mail-wg0-f52.google.com ([74.125.82.52]:46572 "EHLO mail-wg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932120AbaIEKXw (ORCPT ); Fri, 5 Sep 2014 06:23:52 -0400 Date: Fri, 5 Sep 2014 12:23:47 +0200 From: Ingo Molnar To: Toshi Kani Cc: Henrique de Moraes Holschuh , hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140905102347.GA30096@gmail.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <1409862708.28990.141.camel@misato.fc.hp.com> <1409873255.28990.158.camel@misato.fc.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1409873255.28990.158.camel@misato.fc.hp.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Toshi Kani wrote: > On Thu, 2014-09-04 at 14:31 -0600, Toshi Kani wrote: > > On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote: > > > On Thu, 04 Sep 2014, Toshi Kani wrote: > > > > This patch sets WT to the PA4 slot in the PAT MSR when the processor > > > > is not affected by the PAT errata. The upper 4 slots of the PAT MSR > > > > are continued to be unused on the following Intel processors. > > > > > > > > errata cpuid > > > > -------------------------------------- > > > > Pentium 2, A52 family 0x6, model 0x5 > > > > Pentium 3, E27 family 0x6, model 0x7 > > > > Pentium M, Y26 family 0x6, model 0x9 > > > > Pentium 4, N46 family 0xf, model 0x0 > > > > > > > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- > > > > per the default setup in __cachemode2pte_tbl[]. > > > > > > There are at least two PAT errata. The blacklist is in > > > arch/x86/kernel/cpu/intel.c: > > > > > > if (c->x86 == 6 && c->x86_model < 15) > > > clear_cpu_cap(c, X86_FEATURE_PAT); > > > > > > It covers model 13, which is not in your blacklist. > > > > > > It *is* possible that PAT would work on model 13, as I don't think it has > > > any PAT errata listed and it was blacklisted "just in case" (from memory. I > > > did not re-check), but this is untested, and unwise to enable on an aging > > > platform. > > > > > > I am worried of uncharted territory, here. I'd actually advocate for not > > > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > > > is using them as well. Is this a real concern, or am I being overly > > > cautious? > > > > The blacklist you pointed out covers a different PAT errata, and is > > still effective after this change. pat_init() will call pat_disable() > > and the PAT will continue to be disabled on these processors. There is > > no change for them. > > > > My blacklist covers the PAT errata that makes the upper four bit > > unusable when the PAT is enabled. > > I checked more carefully, and it turns out that the processors > that have the WC bug with PAT/MTRR also have the upper four bit > bug in PAT as well. The updated blacklist is: > > errata cpuid > -------------------------------------- > Pentium 2, A52 family 0x6, model 0x5 > Pentium 3, E27 family 0x6, model 0x7, 0x8 > Pentium 3 Xeon, G26 family 0x6, model 0x7, 0x8, 0xa > Pentium M, Y26 family 0x6, model 0x9 > Pentium M 90nm, X9 family 0x6, model 0xd > Pentium 4, N46 family 0xf, model 0x0 > > So, the check can be the same as cpu/intel.c, except that early > Pentium 4 steppings also have the upper four bit bug. I will > update the check. In any case, this check is only meaningful > for P4 since the PAT is disabled for P2/3/M. Any reason why we have to create such a sharp boundary, instead of simply saying: 'disable PAT on all x86 CPU families that have at least one buggy model'? That would nicely sort out all the broken CPUs, and would make it highly unlikely that we'd accidentally forget about a model or two. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932642AbaIEOBP (ORCPT ); Fri, 5 Sep 2014 10:01:15 -0400 Received: from g4t3425.houston.hp.com ([15.201.208.53]:43593 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932323AbaIEOBO (ORCPT ); Fri, 5 Sep 2014 10:01:14 -0400 Message-ID: <1409925023.28990.176.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani To: Ingo Molnar Cc: Henrique de Moraes Holschuh , hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com Date: Fri, 05 Sep 2014 07:50:23 -0600 In-Reply-To: <20140905102347.GA30096@gmail.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <1409862708.28990.141.camel@misato.fc.hp.com> <1409873255.28990.158.camel@misato.fc.hp.com> <20140905102347.GA30096@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2014-09-05 at 12:23 +0200, Ingo Molnar wrote: > * Toshi Kani wrote: > > > On Thu, 2014-09-04 at 14:31 -0600, Toshi Kani wrote: > > > On Thu, 2014-09-04 at 17:11 -0300, Henrique de Moraes Holschuh wrote: > > > > On Thu, 04 Sep 2014, Toshi Kani wrote: > > > > > This patch sets WT to the PA4 slot in the PAT MSR when the processor > > > > > is not affected by the PAT errata. The upper 4 slots of the PAT MSR > > > > > are continued to be unused on the following Intel processors. > > > > > > > > > > errata cpuid > > > > > -------------------------------------- > > > > > Pentium 2, A52 family 0x6, model 0x5 > > > > > Pentium 3, E27 family 0x6, model 0x7 > > > > > Pentium M, Y26 family 0x6, model 0x9 > > > > > Pentium 4, N46 family 0xf, model 0x0 > > > > > > > > > > For these affected processors, _PAGE_CACHE_MODE_WT is redirected to UC- > > > > > per the default setup in __cachemode2pte_tbl[]. > > > > > > > > There are at least two PAT errata. The blacklist is in > > > > arch/x86/kernel/cpu/intel.c: > > > > > > > > if (c->x86 == 6 && c->x86_model < 15) > > > > clear_cpu_cap(c, X86_FEATURE_PAT); > > > > > > > > It covers model 13, which is not in your blacklist. > > > > > > > > It *is* possible that PAT would work on model 13, as I don't think it has > > > > any PAT errata listed and it was blacklisted "just in case" (from memory. I > > > > did not re-check), but this is untested, and unwise to enable on an aging > > > > platform. > > > > > > > > I am worried of uncharted territory, here. I'd actually advocate for not > > > > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > > > > is using them as well. Is this a real concern, or am I being overly > > > > cautious? > > > > > > The blacklist you pointed out covers a different PAT errata, and is > > > still effective after this change. pat_init() will call pat_disable() > > > and the PAT will continue to be disabled on these processors. There is > > > no change for them. > > > > > > My blacklist covers the PAT errata that makes the upper four bit > > > unusable when the PAT is enabled. > > > > I checked more carefully, and it turns out that the processors > > that have the WC bug with PAT/MTRR also have the upper four bit > > bug in PAT as well. The updated blacklist is: > > > > errata cpuid > > -------------------------------------- > > Pentium 2, A52 family 0x6, model 0x5 > > Pentium 3, E27 family 0x6, model 0x7, 0x8 > > Pentium 3 Xeon, G26 family 0x6, model 0x7, 0x8, 0xa > > Pentium M, Y26 family 0x6, model 0x9 > > Pentium M 90nm, X9 family 0x6, model 0xd > > Pentium 4, N46 family 0xf, model 0x0 > > > > So, the check can be the same as cpu/intel.c, except that early > > Pentium 4 steppings also have the upper four bit bug. I will > > update the check. In any case, this check is only meaningful > > for P4 since the PAT is disabled for P2/3/M. > > Any reason why we have to create such a sharp boundary, instead > of simply saying: 'disable PAT on all x86 CPU families that have > at least one buggy model'? > > That would nicely sort out all the broken CPUs, and would make it > highly unlikely that we'd accidentally forget about a model or > two. Agreed. I will disable this feature on all Pentium 4 models as well. I do not think there is any necessity to enable it on Pentium 4. Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932830AbaIEOKr (ORCPT ); Fri, 5 Sep 2014 10:10:47 -0400 Received: from g2t2354.austin.hp.com ([15.217.128.53]:59913 "EHLO g2t2354.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932201AbaIEOKp (ORCPT ); Fri, 5 Sep 2014 10:10:45 -0400 Message-ID: <1409925614.28990.184.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani To: Andy Lutomirski Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Date: Fri, 05 Sep 2014 08:00:14 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2014-09-04 at 17:51 -0700, Andy Lutomirski wrote: > On Thu, Sep 4, 2014 at 5:29 PM, Toshi Kani wrote: > > On Thu, 2014-09-04 at 16:34 -0700, Andy Lutomirski wrote: > >> On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh > >> wrote: > >> > On Thu, 04 Sep 2014, H. Peter Anvin wrote: > >> >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > >> >> > I am worried of uncharted territory, here. I'd actually advocate for not > >> >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > >> >> > is using them as well. Is this a real concern, or am I being overly > >> >> > cautious? > >> >> > >> >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and > >> >> not in 64-bit mode on the same CPU. > >> > > >> > Sure, but is it really a good idea to enable this on the *old* non-64-bit > >> > capable processors (note: I don't mean x86-64 processors operating in 32-bit > >> > mode) ? > >> > > >> >> As far as I know, the current blacklist rule is very conservative due to > >> >> lack of testing more than anything else. > >> > > >> > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted > >> > from using PAT :-) > >> > >> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine > >> is nuts, and not just because I'd be somewhat amazed if it even > >> physically fits into the slot. :) > > > > According to the spec, the upper four entries bug was fixed in Pentium 4 > > model 0x1. So, the remaining Intel 32-bit processors that may enable > > the upper four entries are Pentium 4 model 0x1-4. Should we disable it > > for all Pentium 4 models? > > Assuming that this is Pentium 4 erratum N46, then there may be another > option: use slot 7 instead of slot 4 for WT. Then, even if somehow > the blacklist screws up, the worst that happens is that a WT page gets > interpreted as UC. I suppose this could cause aliasing issues, but > can't cause problems for people who don't use the high entries in the > first place. That's a fine idea, but as Ingo also suggested, I am going to disable this feature on all Pentium 4 models. That should give us a safety margin. Using slot 4 has a benefit that it keeps the PAT setup consistent with Xen. Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756214AbaIEPIO (ORCPT ); Fri, 5 Sep 2014 11:08:14 -0400 Received: from terminus.zytor.com ([198.137.202.10]:47874 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752006AbaIEPIM (ORCPT ); Fri, 5 Sep 2014 11:08:12 -0400 Message-ID: <5409D197.2060900@zytor.com> Date: Fri, 05 Sep 2014 08:07:03 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Toshi Kani , Andy Lutomirski CC: Henrique de Moraes Holschuh , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> <1409925614.28990.184.camel@misato.fc.hp.com> In-Reply-To: <1409925614.28990.184.camel@misato.fc.hp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/05/2014 07:00 AM, Toshi Kani wrote: > > That's a fine idea, but as Ingo also suggested, I am going to disable > this feature on all Pentium 4 models. That should give us a safety > margin. Using slot 4 has a benefit that it keeps the PAT setup > consistent with Xen. > Slot 4 is also the maximally problematic one, because it is the one that might be incorrectly invoked for the page tables themselves. -hpa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754312AbaIEPdZ (ORCPT ); Fri, 5 Sep 2014 11:33:25 -0400 Received: from g4t3426.houston.hp.com ([15.201.208.54]:2372 "EHLO g4t3426.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752212AbaIEPdX (ORCPT ); Fri, 5 Sep 2014 11:33:23 -0400 Message-ID: <1409930574.28990.192.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani To: "H. Peter Anvin" Cc: Andy Lutomirski , Henrique de Moraes Holschuh , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Date: Fri, 05 Sep 2014 09:22:54 -0600 In-Reply-To: <5409D197.2060900@zytor.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> <1409925614.28990.184.camel@misato.fc.hp.com> <5409D197.2060900@zytor.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote: > On 09/05/2014 07:00 AM, Toshi Kani wrote: > > > > That's a fine idea, but as Ingo also suggested, I am going to disable > > this feature on all Pentium 4 models. That should give us a safety > > margin. Using slot 4 has a benefit that it keeps the PAT setup > > consistent with Xen. > > > > Slot 4 is also the maximally problematic one, because it is the one that > might be incorrectly invoked for the page tables themselves. Good point. I wonder if Xen folks feel strongly about keeping the PAT setup consistent with the kernel. If not, we may choose to use slot 6 (or 7). Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753259AbaIEPmL (ORCPT ); Fri, 5 Sep 2014 11:42:11 -0400 Received: from terminus.zytor.com ([198.137.202.10]:48289 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753108AbaIEPmJ (ORCPT ); Fri, 5 Sep 2014 11:42:09 -0400 Message-ID: <5409D99C.10305@zytor.com> Date: Fri, 05 Sep 2014 08:41:16 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Toshi Kani CC: Andy Lutomirski , Henrique de Moraes Holschuh , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> <1409925614.28990.184.camel@misato.fc.hp.com> <5409D197.2060900@zytor.com> <1409930574.28990.192.camel@misato.fc.hp.com> In-Reply-To: <1409930574.28990.192.camel@misato.fc.hp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/05/2014 08:22 AM, Toshi Kani wrote: > On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote: >> On 09/05/2014 07:00 AM, Toshi Kani wrote: >>> >>> That's a fine idea, but as Ingo also suggested, I am going to disable >>> this feature on all Pentium 4 models. That should give us a safety >>> margin. Using slot 4 has a benefit that it keeps the PAT setup >>> consistent with Xen. >>> >> >> Slot 4 is also the maximally problematic one, because it is the one that >> might be incorrectly invoked for the page tables themselves. > > Good point. I wonder if Xen folks feel strongly about keeping the PAT > setup consistent with the kernel. If not, we may choose to use slot 6 > (or 7). > Who cares what the Xen folks "feel strongly about"? If strong feelings were a design criterion Xen support would have been pulled from the kernel a long, long time ago. The important thing is how to design for the situation that we currently have to live with. -hpa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751266AbaIEPxX (ORCPT ); Fri, 5 Sep 2014 11:53:23 -0400 Received: from g6t1524.atlanta.hp.com ([15.193.200.67]:17366 "EHLO g6t1524.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750776AbaIEPxW (ORCPT ); Fri, 5 Sep 2014 11:53:22 -0400 Message-ID: <1409931772.28990.197.camel@misato.fc.hp.com> Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR From: Toshi Kani To: "H. Peter Anvin" Cc: Andy Lutomirski , Henrique de Moraes Holschuh , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Date: Fri, 05 Sep 2014 09:42:52 -0600 In-Reply-To: <5409D99C.10305@zytor.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <1409876991.28990.172.camel@misato.fc.hp.com> <1409925614.28990.184.camel@misato.fc.hp.com> <5409D197.2060900@zytor.com> <1409930574.28990.192.camel@misato.fc.hp.com> <5409D99C.10305@zytor.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2014-09-05 at 08:41 -0700, H. Peter Anvin wrote: > On 09/05/2014 08:22 AM, Toshi Kani wrote: > > On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote: > >> On 09/05/2014 07:00 AM, Toshi Kani wrote: > >>> > >>> That's a fine idea, but as Ingo also suggested, I am going to disable > >>> this feature on all Pentium 4 models. That should give us a safety > >>> margin. Using slot 4 has a benefit that it keeps the PAT setup > >>> consistent with Xen. > >>> > >> > >> Slot 4 is also the maximally problematic one, because it is the one that > >> might be incorrectly invoked for the page tables themselves. > > > > Good point. I wonder if Xen folks feel strongly about keeping the PAT > > setup consistent with the kernel. If not, we may choose to use slot 6 > > (or 7). > > > > Who cares what the Xen folks "feel strongly about"? If strong feelings > were a design criterion Xen support would have been pulled from the > kernel a long, long time ago. > > The important thing is how to design for the situation that we currently > have to live with. I see. Then, I am going to use slot 7 for WT as suggested by Andy. I think it is the safest slot as slot 3 is UC and is not currently used. Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752092AbaIGIth (ORCPT ); Sun, 7 Sep 2014 04:49:37 -0400 Received: from mail-we0-f180.google.com ([74.125.82.180]:48907 "EHLO mail-we0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750840AbaIGItf (ORCPT ); Sun, 7 Sep 2014 04:49:35 -0400 Message-ID: <540C1C01.1000308@plexistor.com> Date: Sun, 07 Sep 2014 11:49:05 +0300 From: Yigal Korman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Toshi Kani , Andy Lutomirski CC: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> In-Reply-To: <1409857025.28990.125.camel@misato.fc.hp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt If it's possible, can you please update pat.txt as part of the patch? Thank you, Yigal On 04/09/2014 21:57, Toshi Kani wrote: > On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote: >> On Thu, Sep 4, 2014 at 11:35 AM, Toshi Kani wrote: >>> This patch adds set_memory_wt(), set_memory_array_wt(), and >>> set_pages_array_wt() for setting range(s) of memory to WT. >>> >> Possibly dumb question: I thought that set_memory_xyz was only for >> RAM. Is that incorrect? > It works for non-RAM ranges as well. For instance, you can use > set_memory_xyz() to change cache attribute for a non-RAM range mapped by > ioremap_cache(). > > Thanks, > -Toshi > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752364AbaIGN7G (ORCPT ); Sun, 7 Sep 2014 09:59:06 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:37302 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752010AbaIGN7E (ORCPT ); Sun, 7 Sep 2014 09:59:04 -0400 X-Sasl-enc: uCzNybXYQPRgouptBFkxgq6syYRoHg70G8Qd3Qo4FUle 1410098343 Date: Sun, 7 Sep 2014 10:58:50 -0300 From: Henrique de Moraes Holschuh To: Toshi Kani Cc: Ingo Molnar , hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, akpm@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgross@suse.com, stefan.bader@canonical.com, luto@amacapital.net, konrad.wilk@oracle.com Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140907135850.GA23026@khazad-dum.debian.net> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <1409862708.28990.141.camel@misato.fc.hp.com> <1409873255.28990.158.camel@misato.fc.hp.com> <20140905102347.GA30096@gmail.com> <1409925023.28990.176.camel@misato.fc.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1409925023.28990.176.camel@misato.fc.hp.com> X-GPG-Fingerprint1: 4096R/39CB4807 C467 A717 507B BAFE D3C1 6092 0BD9 E811 39CB 4807 X-GPG-Fingerprint2: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 05 Sep 2014, Toshi Kani wrote: > On Fri, 2014-09-05 at 12:23 +0200, Ingo Molnar wrote: > > Any reason why we have to create such a sharp boundary, instead > > of simply saying: 'disable PAT on all x86 CPU families that have > > at least one buggy model'? > > > > That would nicely sort out all the broken CPUs, and would make it > > highly unlikely that we'd accidentally forget about a model or > > two. > > Agreed. I will disable this feature on all Pentium 4 models as well. I > do not think there is any necessity to enable it on Pentium 4. Thank you. That takes care of my misguivings about enabling this on aging platforms as well. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752633AbaIGQuH (ORCPT ); Sun, 7 Sep 2014 12:50:07 -0400 Received: from mail-la0-f45.google.com ([209.85.215.45]:43743 "EHLO mail-la0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752542AbaIGQuF (ORCPT ); Sun, 7 Sep 2014 12:50:05 -0400 MIME-Version: 1.0 In-Reply-To: <540C1C01.1000308@plexistor.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> <540C1C01.1000308@plexistor.com> From: Andy Lutomirski Date: Sun, 7 Sep 2014 09:49:41 -0700 Message-ID: Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT To: Yigal Korman Cc: Toshi Kani , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman wrote: > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt > If it's possible, can you please update pat.txt as part of the patch? Indeed. That file seems to indicate several times that the intended use of set_memory_xyz is for RAM. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753964AbaIHPSR (ORCPT ); Mon, 8 Sep 2014 11:18:17 -0400 Received: from g4t3425.houston.hp.com ([15.201.208.53]:14507 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752973AbaIHPSQ (ORCPT ); Mon, 8 Sep 2014 11:18:16 -0400 Message-ID: <1410188863.28990.209.camel@misato.fc.hp.com> Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT From: Toshi Kani To: Andy Lutomirski Cc: Yigal Korman , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader , Konrad Rzeszutek Wilk Date: Mon, 08 Sep 2014 09:07:43 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> <540C1C01.1000308@plexistor.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2014-09-07 at 09:49 -0700, Andy Lutomirski wrote: > On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman wrote: > > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt > > If it's possible, can you please update pat.txt as part of the patch? > > Indeed. That file seems to indicate several times that the intended > use of set_memory_xyz is for RAM. Good point. pat.txt is correct that the "intended" use of set_memory_xyz() is for RAM since there is no other way to set non-WB attribute for RAM. For reserved memory, one should call ioremap_xyz() to map with the xyz attribute directly. From the functionality POV, set_memory_xyz() works for reserved memory, but such usage is not intended. Should I drop the patch 4/5 until we can track the use of WT for RAM? Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754722AbaIHRYE (ORCPT ); Mon, 8 Sep 2014 13:24:04 -0400 Received: from mail-lb0-f182.google.com ([209.85.217.182]:38303 "EHLO mail-lb0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754071AbaIHRYC (ORCPT ); Mon, 8 Sep 2014 13:24:02 -0400 MIME-Version: 1.0 In-Reply-To: <1410188863.28990.209.camel@misato.fc.hp.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> <540C1C01.1000308@plexistor.com> <1410188863.28990.209.camel@misato.fc.hp.com> From: Andy Lutomirski Date: Mon, 8 Sep 2014 10:23:40 -0700 Message-ID: Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT To: Toshi Kani Cc: "linux-mm@kvack.org" , Yigal Korman , Juergen Gross , Arnd Bergmann , Thomas Gleixner , akpm@linuxfoundation.org, Ingo Molnar , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Konrad Rzeszutek Wilk , Stefan Bader Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sep 8, 2014 8:18 AM, "Toshi Kani" wrote: > > On Sun, 2014-09-07 at 09:49 -0700, Andy Lutomirski wrote: > > On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman wrote: > > > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt > > > If it's possible, can you please update pat.txt as part of the patch? > > > > Indeed. That file seems to indicate several times that the intended > > use of set_memory_xyz is for RAM. > > > Good point. pat.txt is correct that the "intended" use of > set_memory_xyz() is for RAM since there is no other way to set non-WB > attribute for RAM. For reserved memory, one should call ioremap_xyz() > to map with the xyz attribute directly. From the functionality POV, > set_memory_xyz() works for reserved memory, but such usage is not > intended. > > Should I drop the patch 4/5 until we can track the use of WT for RAM? Probably not. I can imagine someone ioremapping a huge chunk of NV-DIMM and then wanting to change some of it to WT. Unless I've missed something (which is rather likely), the cleanest way to do this is with set_memory_wt. If that happens, someone should update pat.txt to indicate that it's allowed. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754169AbaIHSwg (ORCPT ); Mon, 8 Sep 2014 14:52:36 -0400 Received: from g4t3426.houston.hp.com ([15.201.208.54]:6955 "EHLO g4t3426.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750992AbaIHSwf (ORCPT ); Mon, 8 Sep 2014 14:52:35 -0400 Message-ID: <1410201722.28990.219.camel@misato.fc.hp.com> Subject: Re: [PATCH 4/5] x86, mm: Add set_memory_wt() for WT From: Toshi Kani To: Andy Lutomirski Cc: "linux-mm@kvack.org" , Yigal Korman , Juergen Gross , Arnd Bergmann , Thomas Gleixner , akpm@linuxfoundation.org, Ingo Molnar , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Konrad Rzeszutek Wilk , Stefan Bader Date: Mon, 08 Sep 2014 12:42:02 -0600 In-Reply-To: References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-5-git-send-email-toshi.kani@hp.com> <1409857025.28990.125.camel@misato.fc.hp.com> <540C1C01.1000308@plexistor.com> <1410188863.28990.209.camel@misato.fc.hp.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2014-09-08 at 10:23 -0700, Andy Lutomirski wrote: > On Sep 8, 2014 8:18 AM, "Toshi Kani" wrote: > > > > On Sun, 2014-09-07 at 09:49 -0700, Andy Lutomirski wrote: > > > On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman wrote: > > > > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt > > > > If it's possible, can you please update pat.txt as part of the patch? > > > > > > Indeed. That file seems to indicate several times that the intended > > > use of set_memory_xyz is for RAM. > > > > > > Good point. pat.txt is correct that the "intended" use of > > set_memory_xyz() is for RAM since there is no other way to set non-WB > > attribute for RAM. For reserved memory, one should call ioremap_xyz() > > to map with the xyz attribute directly. From the functionality POV, > > set_memory_xyz() works for reserved memory, but such usage is not > > intended. > > > > Should I drop the patch 4/5 until we can track the use of WT for RAM? > > Probably not. I can imagine someone ioremapping a huge chunk of > NV-DIMM and then wanting to change some of it to WT. Unless I've > missed something (which is rather likely), the cleanest way to do this > is with set_memory_wt. Yeah, that sounds possible. > If that happens, someone should update pat.txt to indicate that it's allowed. Since it is unlikely that someone will update pat.txt later, I will update it to: ------------------------------------------------------------------- API | RAM | ACPI,... | Reserved/Holes | -----------------------|----------|------------|------------------| set_memory_wt | *1 | -- | WT | set_memory_wb | | | | *1: -EINVAL due to the current limitation in reserve_memtype(). Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752383AbaILTZj (ORCPT ); Fri, 12 Sep 2014 15:25:39 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:38297 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751186AbaILTZi (ORCPT ); Fri, 12 Sep 2014 15:25:38 -0400 Date: Fri, 12 Sep 2014 15:25:01 -0400 From: Konrad Rzeszutek Wilk To: Andy Lutomirski Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Toshi Kani , Thomas Gleixner , Ingo Molnar , akpm@linuxfoundation.org, Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140912192501.GG15656@laptop.dumpdata.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 04, 2014 at 04:34:43PM -0700, Andy Lutomirski wrote: > On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh > wrote: > > On Thu, 04 Sep 2014, H. Peter Anvin wrote: > >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > >> > I am worried of uncharted territory, here. I'd actually advocate for not > >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / XP > >> > is using them as well. Is this a real concern, or am I being overly > >> > cautious? > >> > >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and > >> not in 64-bit mode on the same CPU. > > > > Sure, but is it really a good idea to enable this on the *old* non-64-bit > > capable processors (note: I don't mean x86-64 processors operating in 32-bit > > mode) ? > > > >> As far as I know, the current blacklist rule is very conservative due to > >> lack of testing more than anything else. > > > > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted > > from using PAT :-) > > At the very least, anyone who plugs an NV-DIMM into a 32-bit machine > is nuts, and not just because I'd be somewhat amazed if it even > physically fits into the slot. :) They do have PCIe to PCI adapters, so you _could_ do it :-) > > --Andy > > > > > -- > > "One disk to rule them all, One disk to find them. One disk to bring > > them all and in the darkness grind them. In the Land of Redmond > > where the shadows lie." -- The Silicon Valley Tarot > > Henrique Holschuh > > > > -- > Andy Lutomirski > AMA Capital Management, LLC From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752323AbaILUDe (ORCPT ); Fri, 12 Sep 2014 16:03:34 -0400 Received: from mail-la0-f42.google.com ([209.85.215.42]:41362 "EHLO mail-la0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751726AbaILUDd (ORCPT ); Fri, 12 Sep 2014 16:03:33 -0400 MIME-Version: 1.0 In-Reply-To: <20140912192501.GG15656@laptop.dumpdata.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <20140912192501.GG15656@laptop.dumpdata.com> From: Andy Lutomirski Date: Fri, 12 Sep 2014 13:03:12 -0700 Message-ID: Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR To: Konrad Rzeszutek Wilk Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Toshi Kani , Thomas Gleixner , Ingo Molnar , Andrew Morton , Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 12, 2014 at 12:25 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 04, 2014 at 04:34:43PM -0700, Andy Lutomirski wrote: >> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine >> is nuts, and not just because I'd be somewhat amazed if it even >> physically fits into the slot. :) > > They do have PCIe to PCI adapters, so you _could_ do it :-) > My NV-DIMMs are DDR3 RDIMMs, so it would be a very magical adapter indeed. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752781AbaILUWM (ORCPT ); Fri, 12 Sep 2014 16:22:12 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:20305 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751726AbaILUWK (ORCPT ); Fri, 12 Sep 2014 16:22:10 -0400 Date: Fri, 12 Sep 2014 16:21:38 -0400 From: Konrad Rzeszutek Wilk To: Andy Lutomirski Cc: Henrique de Moraes Holschuh , "H. Peter Anvin" , Toshi Kani , Thomas Gleixner , Ingo Molnar , Andrew Morton , Arnd Bergmann , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Juergen Gross , Stefan Bader Subject: Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR Message-ID: <20140912202138.GA24501@laptop.dumpdata.com> References: <1409855739-8985-1-git-send-email-toshi.kani@hp.com> <1409855739-8985-2-git-send-email-toshi.kani@hp.com> <20140904201123.GA9116@khazad-dum.debian.net> <5408C9C4.1010705@zytor.com> <20140904231923.GA15320@khazad-dum.debian.net> <20140912192501.GG15656@laptop.dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 12, 2014 at 01:03:12PM -0700, Andy Lutomirski wrote: > On Fri, Sep 12, 2014 at 12:25 PM, Konrad Rzeszutek Wilk > wrote: > > On Thu, Sep 04, 2014 at 04:34:43PM -0700, Andy Lutomirski wrote: > >> At the very least, anyone who plugs an NV-DIMM into a 32-bit machine > >> is nuts, and not just because I'd be somewhat amazed if it even > >> physically fits into the slot. :) > > > > They do have PCIe to PCI adapters, so you _could_ do it :-) > > > > My NV-DIMMs are DDR3 RDIMMs, so it would be a very magical adapter indeed. I misread that as 'NVME', duh! > > --Andy