[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org>
Date: Fri, 24 Jul 2020 08:33:12 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Alex Ghiti <alex@...ti.fr>, Palmer Dabbelt <palmer@...belt.com>
Cc: mpe@...erman.id.au, paulus@...ba.org,
Paul Walmsley <paul.walmsley@...ive.com>,
aou@...s.berkeley.edu, Anup Patel <Anup.Patel@....com>,
Atish Patra <Atish.Patra@....com>, zong.li@...ive.com,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-riscv@...ts.infradead.org, linux-mm@...ck.org
Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone
On Thu, 2020-07-23 at 01:21 -0400, Alex Ghiti wrote:
> > works fine with huge pages, what is your problem there ? You rely on
> > punching small-page size holes in there ?
> >
>
> ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel
> mapping in the direct mapping as it sets different permissions to
> different part of the kernel (data, text..etc).
Ah ok, that can be solved in a couple of ways...
One is to use the linker script to ensure those sections are linked
HUGE_PAGE_SIZE appart and moved appropriately by early boot code. One
is to selectively degrade just those huge pages.
I'm not familiar with the RiscV MMU (I should probably go have a look)
but if it's a classic radix tree with huge pages at PUD/PMD level, then
you could just degrade the one(s) that cross those boundaries.
Cheers,
Ben.
Powered by blists - more mailing lists