From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alex Ghiti <alex@ghiti.fr>, Palmer Dabbelt <palmer@dabbelt.com>
Cc: mpe@ellerman.id.au, paulus@samba.org,
Paul Walmsley <paul.walmsley@sifive.com>,
aou@eecs.berkeley.edu, Anup Patel <Anup.Patel@wdc.com>,
Atish Patra <Atish.Patra@wdc.com>,
zong.li@sifive.com, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-mm@kvack.org
Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone
Date: Fri, 24 Jul 2020 08:33:12 +1000 [thread overview]
Message-ID: <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> (raw)
In-Reply-To: <cade70e2-0179-2650-41c5-036679aaf30c@ghiti.fr>
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.
next prev parent reply other threads:[~2020-07-23 22:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mhng-831c4073-aefa-4aa0-a583-6a17f9aff9b7@palmerdabbelt-glaptop1>
[not found] ` <d7e3cbb7-c12a-bce2-f1db-c336d15f74bd@ghiti.fr>
2020-07-21 18:36 ` Alex Ghiti
2020-07-21 19:05 ` Palmer Dabbelt
2020-07-21 23:12 ` Benjamin Herrenschmidt
2020-07-21 23:48 ` Palmer Dabbelt
2020-07-22 2:21 ` Benjamin Herrenschmidt
2020-07-22 4:50 ` Michael Ellerman
2020-07-22 5:46 ` Palmer Dabbelt
2020-07-22 9:43 ` Arnd Bergmann
2020-07-22 19:52 ` Palmer Dabbelt
2020-07-22 20:22 ` Arnd Bergmann
2020-07-22 21:05 ` Atish Patra
2020-07-24 7:20 ` Arnd Bergmann
2020-07-23 5:32 ` Alex Ghiti
2020-07-21 23:11 ` Benjamin Herrenschmidt
2020-07-21 23:36 ` Palmer Dabbelt
2020-07-23 5:36 ` Alex Ghiti
2020-07-23 5:21 ` Alex Ghiti
2020-07-23 22:33 ` Benjamin Herrenschmidt [this message]
2020-07-24 8:14 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=Anup.Patel@wdc.com \
--cc=Atish.Patra@wdc.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=paulus@samba.org \
--cc=zong.li@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox