From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E4B8C433E1 for ; Thu, 23 Jul 2020 05:22:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 474C120768 for ; Thu, 23 Jul 2020 05:22:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 474C120768 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ghiti.fr Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D92806B0006; Thu, 23 Jul 2020 01:22:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D42DA6B0007; Thu, 23 Jul 2020 01:22:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C58C06B0008; Thu, 23 Jul 2020 01:22:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0246.hostedemail.com [216.40.44.246]) by kanga.kvack.org (Postfix) with ESMTP id AC9A96B0006 for ; Thu, 23 Jul 2020 01:22:01 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6982B30037 for ; Thu, 23 Jul 2020 05:22:01 +0000 (UTC) X-FDA: 77068194042.23.birds99_2a0ca7926f3c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 3BB7924B36 for ; Thu, 23 Jul 2020 05:22:01 +0000 (UTC) X-HE-Tag: birds99_2a0ca7926f3c X-Filterd-Recvd-Size: 3837 Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Thu, 23 Jul 2020 05:22:00 +0000 (UTC) X-Originating-IP: 90.112.45.105 Received: from [192.168.1.14] (lfbn-gre-1-325-105.w90-112.abo.wanadoo.fr [90.112.45.105]) (Authenticated sender: alex@ghiti.fr) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 722BD60002; Thu, 23 Jul 2020 05:21:51 +0000 (UTC) Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone To: Benjamin Herrenschmidt , Palmer Dabbelt Cc: mpe@ellerman.id.au, paulus@samba.org, Paul Walmsley , aou@eecs.berkeley.edu, Anup Patel , Atish Patra , zong.li@sifive.com, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-mm@kvack.org References: <7cb2285e-68ba-6827-5e61-e33a4b65ac03@ghiti.fr> <54af168083aee9dbda1b531227521a26b77ba2c8.camel@kernel.crashing.org> From: Alex Ghiti Message-ID: Date: Thu, 23 Jul 2020 01:21:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <54af168083aee9dbda1b531227521a26b77ba2c8.camel@kernel.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr X-Rspamd-Queue-Id: 3BB7924B36 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.001057, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Benjamin, Le 7/21/20 =C3=A0 7:11 PM, Benjamin Herrenschmidt a =C3=A9crit=C2=A0: > On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote: >>>> I guess I don't understand why this is necessary at all. >>>> Specifically: why >>>> can't we just relocate the kernel within the linear map? That would >>>> let the >>>> bootloader put the kernel wherever it wants, modulo the physical >>>> memory size we >>>> support. We'd need to handle the regions that are coupled to the >>>> kernel's >>>> execution address, but we could just put them in an explicit memory >>>> region >>>> which is what we should probably be doing anyway. >>> >>> Virtual relocation in the linear mapping requires to move the kernel >>> physically too. Zong implemented this physical move in its KASLR RFC >>> patchset, which is cumbersome since finding an available physical spo= t >>> is harder than just selecting a virtual range in the vmalloc range. >>> >>> In addition, having the kernel mapping in the linear mapping prevents >>> the use of hugepage for the linear mapping resulting in performance l= oss >>> (at least for the GB that encompasses the kernel). >>> >>> Why do you find this "ugly" ? The vmalloc region is just a bunch of >>> available virtual addresses to whatever purpose we want, and as noted= by >>> Zong, arm64 uses the same scheme. >=20 > I don't get it :-) >=20 > At least on powerpc we move the kernel in the linear mapping and it > works fine with huge pages, what is your problem there ? You rely on > punching small-page size holes in there ? >=20 ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel=20 mapping in the direct mapping as it sets different permissions to=20 different part of the kernel (data, text..etc). > At least in the old days, there were a number of assumptions that > the kernel text/data/bss resides in the linear mapping. >=20 > If you change that you need to ensure that it's still physically > contiguous and you'll have to tweak __va and __pa, which might induce > extra overhead. >=20 Yes that's done in this patch and indeed there is an overhead to those=20 functions. > Cheers, > Ben. > =20 >=20 Thanks, Alex