Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH] x86/i386: Check PSE bit before using PAGE_KERNEL_LARGE.

14 views
Skip to first unread message

Konrad Rzeszutek Wilk

unread,
May 31, 2012, 3:50:02 PM5/31/12
to
During bootup we would unconditionally do this on any
machine that was built with CONFIG_NUMA=y on i386:

setup_arch
\-initmem_init
\-x86_numa_init (with dummy_init as callback)
\- init_alloc_remap
\- set_pmd_pfn (with PAGE_PSE)

without checking to see if the CPU supports PSE. This
patch adds that and also allows the init_alloc_remap function
to properly work by falling back on PTEs.

CC: sta...@kernel.org
Tested-by: William Dauchy <wda...@gmail.com>
Signed-off-by: Konrad Rzeszutek Wilk <konra...@oracle.com>
---
arch/x86/mm/pgtable_32.c | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)

diff --git a/arch/x86/mm/pgtable_32.c b/arch/x86/mm/pgtable_32.c
index a69bcb8..9fd4abc 100644
--- a/arch/x86/mm/pgtable_32.c
+++ b/arch/x86/mm/pgtable_32.c
@@ -86,7 +86,30 @@ void set_pmd_pfn(unsigned long vaddr, unsigned long pfn, pgprot_t flags)
}
pud = pud_offset(pgd, vaddr);
pmd = pmd_offset(pud, vaddr);
- set_pmd(pmd, pfn_pmd(pfn, flags));
+
+ if ((!cpu_has_pse) && (pgprot_val(flags) & _PAGE_PSE)) {
+ pte_t *pte;
+ int i;
+
+ pgprot_val(flags) &= ~_PAGE_PSE;
+
+ /*
+ * This is run _after_ initial memory mapped so the
+ * PTE page are allocated - but we check it just in case.
+ */
+ if (pmd_none(*pmd)) {
+ printk(KERN_WARNING "set_pmd_pfn: pmd_none\n");
+ return;
+ }
+
+ pte = (pte_t *)pmd_page_vaddr(*pmd);
+ for (i = 0; i < PTRS_PER_PTE; i++) {
+ set_pte(pte, pfn_pte(pfn + i, flags));
+ pte++;
+ }
+ } else
+ set_pmd(pmd, pfn_pmd(pfn, flags));
+
/*
* It's enough to flush this one mapping.
* (PGE mappings get flushed as well)
--
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

H. Peter Anvin

unread,
May 31, 2012, 4:30:02 PM5/31/12
to
On 05/31/2012 12:40 PM, Konrad Rzeszutek Wilk wrote:
> During bootup we would unconditionally do this on any
> machine that was built with CONFIG_NUMA=y on i386:
>
> setup_arch
> \-initmem_init
> \-x86_numa_init (with dummy_init as callback)
> \- init_alloc_remap
> \- set_pmd_pfn (with PAGE_PSE)
>
> without checking to see if the CPU supports PSE. This
> patch adds that and also allows the init_alloc_remap function
> to properly work by falling back on PTEs.
>

Well, the code looks like it is PAE-specific, and PAE implies PSE.

Xen breaks that, but that is a divergence of Xen from x86.

-hpa

Konrad Rzeszutek Wilk

unread,
May 31, 2012, 4:50:02 PM5/31/12
to
On Thu, May 31, 2012 at 01:21:02PM -0700, H. Peter Anvin wrote:
> On 05/31/2012 12:40 PM, Konrad Rzeszutek Wilk wrote:
> > During bootup we would unconditionally do this on any
> > machine that was built with CONFIG_NUMA=y on i386:
> >
> > setup_arch
> > \-initmem_init
> > \-x86_numa_init (with dummy_init as callback)
> > \- init_alloc_remap
> > \- set_pmd_pfn (with PAGE_PSE)
> >
> > without checking to see if the CPU supports PSE. This
> > patch adds that and also allows the init_alloc_remap function
> > to properly work by falling back on PTEs.
> >
>
> Well, the code looks like it is PAE-specific, and PAE implies PSE.

I have to double check - but I think a kernel built with CONFIG_HIGHMEM64=y
and CONFIG_NUMA=y would boot on a Pentium II which can't do PAE.

But perhaps there are some other checks that would halt the kernel
before it even got there?

>
> Xen breaks that, but that is a divergence of Xen from x86.

It certainly does <sigh>. And that is how I spotted this - b/c the
PMD would fail (with tons of mutlicalls warnings) - and the PTE's
would still point to the old PFNs.

H. Peter Anvin

unread,
May 31, 2012, 7:10:01 PM5/31/12
to
No, PAE kernels cannot boot on non-PAE hardware.

Konrad Rzeszutek Wilk <konra...@oracle.com> wrote:

>On Thu, May 31, 2012 at 01:21:02PM -0700, H. Peter Anvin wrote:
>> On 05/31/2012 12:40 PM, Konrad Rzeszutek Wilk wrote:
>> > During bootup we would unconditionally do this on any
>> > machine that was built with CONFIG_NUMA=y on i386:
>> >
>> > setup_arch
>> > \-initmem_init
>> > \-x86_numa_init (with dummy_init as callback)
>> > \- init_alloc_remap
>> > \- set_pmd_pfn (with PAGE_PSE)
>> >
>> > without checking to see if the CPU supports PSE. This
>> > patch adds that and also allows the init_alloc_remap function
>> > to properly work by falling back on PTEs.
>> >
>>
>> Well, the code looks like it is PAE-specific, and PAE implies PSE.
>
>I have to double check - but I think a kernel built with
>CONFIG_HIGHMEM64=y
>and CONFIG_NUMA=y would boot on a Pentium II which can't do PAE.
>
>But perhaps there are some other checks that would halt the kernel
>before it even got there?
>
>>
>> Xen breaks that, but that is a divergence of Xen from x86.
>
>It certainly does <sigh>. And that is how I spotted this - b/c the
>PMD would fail (with tons of mutlicalls warnings) - and the PTE's
>would still point to the old PFNs.

--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
0 new messages