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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 BFA2BC43381 for ; Thu, 11 Mar 2021 08:42:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1EBF064F87 for ; Thu, 11 Mar 2021 08:42:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1EBF064F87 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6F7108D0292; Thu, 11 Mar 2021 03:42:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A5B68D028E; Thu, 11 Mar 2021 03:42:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AB518D0292; Thu, 11 Mar 2021 03:42:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0196.hostedemail.com [216.40.44.196]) by kanga.kvack.org (Postfix) with ESMTP id 28F1A8D028E for ; Thu, 11 Mar 2021 03:42:23 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E44D1180ACEEC for ; Thu, 11 Mar 2021 08:42:22 +0000 (UTC) X-FDA: 77906951724.23.ADE3DDD Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) by imf23.hostedemail.com (Postfix) with ESMTP id 6E201A0000FA for ; Thu, 11 Mar 2021 08:42:21 +0000 (UTC) Received: from mail-oi1-f169.google.com ([209.85.167.169]) by mrelayeu.kundenserver.de (mreue011 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MbRwP-1lqrcj20Er-00bvzi for ; Thu, 11 Mar 2021 09:42:20 +0100 Received: by mail-oi1-f169.google.com with SMTP id d16so13039022oic.0 for ; Thu, 11 Mar 2021 00:42:19 -0800 (PST) X-Gm-Message-State: AOAM533WwzSS4o7wHP0cozLJ2qz8JxDLKhZinnzHrtXqUVSW92psqSkZ ZAVLe6w6mJZlibXhqJPbEPhgbKSneZuSnyABrtY= X-Google-Smtp-Source: ABdhPJw0KtsLD5mW4MfRrfYgVjcEGOdTXZu9D7NdBG3jZg8HvDppDRmR8vUGXG+YVlxNPnM5Hk4ZbDjA/u/ZDR28oc4= X-Received: by 2002:a05:6808:3d9:: with SMTP id o25mr5663752oie.4.1615452138884; Thu, 11 Mar 2021 00:42:18 -0800 (PST) MIME-Version: 1.0 References: <20210225080453.1314-1-alex@ghiti.fr> <20210225080453.1314-3-alex@ghiti.fr> <5279e97c-3841-717c-2a16-c249a61573f9@redhat.com> <7d9036d9-488b-47cc-4673-1b10c11baad0@ghiti.fr> <236a9788-8093-9876-a024-b0ad0d672c72@ghiti.fr> In-Reply-To: <236a9788-8093-9876-a024-b0ad0d672c72@ghiti.fr> From: Arnd Bergmann Date: Thu, 11 Mar 2021 09:42:01 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout To: Alexandre Ghiti Cc: David Hildenbrand , Jonathan Corbet , Paul Walmsley , Palmer Dabbelt , Albert Ou , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , "open list:DOCUMENTATION" , linux-riscv , "linux-kernel@vger.kernel.org" , kasan-dev , linux-arch , Linux-MM , Linus Walleij Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:yZu3SyDo4c0JHc/C774mq2XIDB2BPQBdNkvy2UB0W6HZJdEW5sb liavWnTvQt6tA9T69JVc8G8JW5tk6PIwPbd9NykUYpMVrXAL3jdolsfTl4p+Z6psCs2IZwY yd4d9+FJKRzPixNo3klCuXm62TFbnKnHQirXgoG0xYguDv/zzrYuCv3uMVp1+ygooEd8wzp ZB5sC9D16B8YJ+EFlgsLw== X-UI-Out-Filterresults: notjunk:1;V03:K0:N05LN2OA1ps=:YoRPuPtiB7To3qR6BF5dWm 5wuc5ucSLL9YgCuHrj/7nDGfXIjKGoTa9r7XPSMgox4vVzyz6IuEFl/pS7OxFFlTG04uorKIl 3iWJxv4Dll5hHIGX0ofxq9aRe5Y3pJ8iWtnBAVQYJNNKBn1Ug9iJIg9yVXw8XQRXSR+UKQ5Qw yzvk5IgdYusqL5h6k/FJTuShPoxTBFP6rURU9ucpkIRNPvr5KJ0c88Nl6bO3sluXsnHzxund5 GwhG/kl3ADsUkr4R2+gvsbXMsvSBjy4Dd+Gu9AaxcGsl0pOgtX4OX4cZAt5BoHIE86XNdiEHh Gcb6IWvZXuVC2nQu4d+Hq+agoKJVHEzPRf84rQ+rHTGV5ZaK7DmU5LBeTdWwiltx80/E1l7mE SZHLysd8NW6Yw2JTymZi1rna2Yf3Y/JyDZsC3yuF4fBu7on/VZtDGGx6R+H/D X-Stat-Signature: i9bypjusqe5cepujgcjw56zifpmsxqhw X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 6E201A0000FA Received-SPF: none (arndb.de>: No applicable sender policy available) receiver=imf23; identity=mailfrom; envelope-from=""; helo=mout.kundenserver.de; client-ip=212.227.126.133 X-HE-DKIM-Result: none/none X-HE-Tag: 1615452141-427431 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 10, 2021 at 8:12 PM Alex Ghiti wrote: > Le 3/10/21 =C3=A0 6:42 AM, Arnd Bergmann a =C3=A9crit : > > On Thu, Feb 25, 2021 at 12:56 PM Alex Ghiti wrote: > >> > >> Le 2/25/21 =C3=A0 5:34 AM, David Hildenbrand a =C3=A9crit : > >>> | | | |> + > >>> ffffffc000000000 | -256 GB | ffffffc7ffffffff | 32 GB | kasan > >>>> + ffffffcefee00000 | -196 GB | ffffffcefeffffff | 2 MB | fix= map > >>>> + ffffffceff000000 | -196 GB | ffffffceffffffff | 16 MB | PCI= io > >>>> + ffffffcf00000000 | -196 GB | ffffffcfffffffff | 4 GB | vme= mmap > >>>> + ffffffd000000000 | -192 GB | ffffffdfffffffff | 64 GB | > >>>> vmalloc/ioremap space > >>>> + ffffffe000000000 | -128 GB | ffffffff7fffffff | 126 GB | > >>>> direct mapping of all physical memory > >>> > >>> ^ So you could never ever have more than 126 GB, correct? > >>> > >>> I assume that's nothing new. > >>> > >> > >> Before this patch, the limit was 128GB, so in my sense, there is nothi= ng > >> new. If ever we want to increase that limit, we'll just have to lower > >> PAGE_OFFSET, there is still some unused virtual addresses after kasan > >> for example. > > > > Linus Walleij is looking into changing the arm32 code to have the kerne= l > > direct map inside of the vmalloc area, which would be another place > > that you could use here. It would be nice to not have too many differen= t > > ways of doing this, but I'm not sure how hard it would be to rework you= r > > code, or if there are any downsides of doing this. > > This was what my previous version did: https://lkml.org/lkml/2020/6/7/28. > > This approach was not welcomed very well and it fixed only the problem > of the implementation of relocatable kernel. The second issue I'm trying > to resolve here is to support both 3 and 4 level page tables using the > same kernel without being relocatable (which would introduce performance > penalty). I can't do it when the kernel mapping is in the vmalloc region > since vmalloc region relies on PAGE_OFFSET which is different on both 3 > and 4 level page table and that would then require the kernel to be > relocatable. Ok, I see. I suppose it might work if you moved the direct-map to the lowest address and the vmalloc area (incorporating the kernel mapping, modules, pio, and fixmap at fixed addresses) to the very top of the address space, but you probably already considered and rejected that for other reasons. Arnd