Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp2148835pxf; Sat, 20 Mar 2021 06:05:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxBjEIjT0BVEtUI3yPESAVq+64YBJTfBnbtpbPRUIniC7YOHCvt84m9A71X4jIEzCyEnizR X-Received: by 2002:adf:fa41:: with SMTP id y1mr9168458wrr.256.1616245524659; Sat, 20 Mar 2021 06:05:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616245524; cv=none; d=google.com; s=arc-20160816; b=OUv1hUBH6y1IN8tx7Adw31sXCyi90gawJMc95NJpFwvWX+Q8c52cHP68YZWhBh3q9C IDNXn8VCeExrSKA2YYRapPYlBA9/6BJ71tDNj3sZzNI5kRBgut1rkroqg4LU9v8Fuk7T APOp3U90cMbO9iKZqmfDOKIwh/TMrIXDDvLt5y8NDwQeXOgiSOpqV7xKBtfzdPRYRlvO 3EzrVjban9Uvrp476oRNzHEbzIKWL7qF6pFN8vCgY35+umOdwDCPBMDuQ2h54+p3YnpW 5yZLNAvYuJhqJwKMHpNA482VTq469xCObX4GK879K1JT9Ai5/uSN2vC7PrXf0LAEmO3C rLtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=lN9plnuKkpbJzQLXMCLzC6M7ry/HHd2YVAkTMHBXoC8=; b=OF8CfaQ7G4ADVCKiLlZDqxPNyk7ujUp/ZcnpJsG1oaorTCxx/LWoNhoS12hHZbkXC7 sjPE3Oq6RjsXWQ8kUNTLdPtazNt1zJdzEy6FiQGYeGjLLLrpkTIG+4ri4vQy99UqjwHs OaHC0+ebbcHlIWcfldtdI+0ezOgG+3ZJj7/EBjIV3xF+zOIIM8LPcUWNaRkyze17QkxV C6LxfAy+dTTP5cW/xA7OwVQRhReKsVzhAXyxbN8pvdbMFMzF9sfXUeYADgOfwBcGX9gK gDEtSyyYI1ItaPFDF2COiJp4cuiT73ONspY4gxdV51JHCEIKAm0BijqVO/q8Xk0w34ej IBhA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i15si7344631wrs.46.2021.03.20.06.04.59; Sat, 20 Mar 2021 06:05:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229638AbhCTNAw (ORCPT + 99 others); Sat, 20 Mar 2021 09:00:52 -0400 Received: from mslow2.mail.gandi.net ([217.70.178.242]:50809 "EHLO mslow2.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbhCTNAj (ORCPT ); Sat, 20 Mar 2021 09:00:39 -0400 Received: from relay2-d.mail.gandi.net (unknown [217.70.183.194]) by mslow2.mail.gandi.net (Postfix) with ESMTP id D5C353B566D; Sat, 20 Mar 2021 08:49:40 +0000 (UTC) X-Originating-IP: 2.7.49.219 Received: from [192.168.1.12] (lfbn-lyo-1-457-219.w2-7.abo.wanadoo.fr [2.7.49.219]) (Authenticated sender: alex@ghiti.fr) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 39AEC40003; Sat, 20 Mar 2021 08:48:14 +0000 (UTC) Subject: Re: [PATCH 0/3] Move kernel mapping outside the linear mapping To: Palmer Dabbelt Cc: corbet@lwn.net, Paul Walmsley , aou@eecs.berkeley.edu, Arnd Bergmann , aryabinin@virtuozzo.com, glider@google.com, dvyukov@google.com, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-arch@vger.kernel.org, linux-mm@kvack.org References: From: Alex Ghiti Message-ID: Date: Sat, 20 Mar 2021 04:48:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 3/9/21 à 9:54 PM, Palmer Dabbelt a écrit : > On Thu, 25 Feb 2021 00:04:50 PST (-0800), alex@ghiti.fr wrote: >> I decided to split sv48 support in small series to ease the review. >> >> This patchset pushes the kernel mapping (modules and BPF too) to the last >> 4GB of the 64bit address space, this allows to: >> - implement relocatable kernel (that will come later in another >>   patchset) that requires to move the kernel mapping out of the linear >>   mapping to avoid to copy the kernel at a different physical address. >> - have a single kernel that is not relocatable (and then that avoids the >>   performance penalty imposed by PIC kernel) for both sv39 and sv48. >> >> The first patch implements this behaviour, the second patch introduces a >> documentation that describes the virtual address space layout of the >> 64bit >> kernel and the last patch is taken from my sv48 series where I simply >> added >> the dump of the modules/kernel/BPF mapping. >> >> I removed the Reviewed-by on the first patch since it changed enough from >> last time and deserves a second look. >> >> Alexandre Ghiti (3): >>   riscv: Move kernel mapping outside of linear mapping >>   Documentation: riscv: Add documentation that describes the VM layout >>   riscv: Prepare ptdump for vm layout dynamic addresses >> >>  Documentation/riscv/index.rst       |  1 + >>  Documentation/riscv/vm-layout.rst   | 61 ++++++++++++++++++++++ >>  arch/riscv/boot/loader.lds.S        |  3 +- >>  arch/riscv/include/asm/page.h       | 18 ++++++- >>  arch/riscv/include/asm/pgtable.h    | 37 +++++++++---- >>  arch/riscv/include/asm/set_memory.h |  1 + >>  arch/riscv/kernel/head.S            |  3 +- >>  arch/riscv/kernel/module.c          |  6 +-- >>  arch/riscv/kernel/setup.c           |  3 ++ >>  arch/riscv/kernel/vmlinux.lds.S     |  3 +- >>  arch/riscv/mm/fault.c               | 13 +++++ >>  arch/riscv/mm/init.c                | 81 +++++++++++++++++++++++------ >>  arch/riscv/mm/kasan_init.c          |  9 ++++ >>  arch/riscv/mm/physaddr.c            |  2 +- >>  arch/riscv/mm/ptdump.c              | 67 +++++++++++++++++++----- >>  15 files changed, 258 insertions(+), 50 deletions(-) >>  create mode 100644 Documentation/riscv/vm-layout.rst > > This generally looks good, but I'm getting a bunch of checkpatch > warnings and some conflicts, do you mind fixing those up (and including > your other kasan patch, as that's likely to conflict)? I have just tried to rebase this on for-next, and that quite conflicts with Vitaly's XIP patch, I'm fixing this and post a v3. Alex