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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFC8BC61DA4 for ; Mon, 13 Mar 2023 09:43:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 438CF6B0071; Mon, 13 Mar 2023 05:43:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E79F6B0072; Mon, 13 Mar 2023 05:43:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D7CC6B0074; Mon, 13 Mar 2023 05:43:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1E68D6B0071 for ; Mon, 13 Mar 2023 05:43:12 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E1B73120879 for ; Mon, 13 Mar 2023 09:43:11 +0000 (UTC) X-FDA: 80563386582.16.015E315 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf17.hostedemail.com (Postfix) with ESMTP id 100DB40004 for ; Mon, 13 Mar 2023 09:43:09 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=h3TDpuYD; spf=pass (imf17.hostedemail.com: domain of ajones@ventanamicro.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=ajones@ventanamicro.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678700590; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DxxClasutQ5PqW8TvU53BWsXOs7xcuC+RTlUJtJP2sQ=; b=zroQahZlbUtJysPiHFw1LiRITONfv2Ygl49WbKfdsCThhPnRXf+Ib5133kEicS+f36EK+C P0zxY3ZkV7aidVqGpj+A7IcoIfJdGYviys6Gr/rSR3dzP7MzFt6gSLFgFxjlLTGUMPxqVz 4uSRj0yTlH2zAUjnLnCnerjICqaTvwo= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=h3TDpuYD; spf=pass (imf17.hostedemail.com: domain of ajones@ventanamicro.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=ajones@ventanamicro.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678700590; a=rsa-sha256; cv=none; b=UUzgChZ5ZoVTwdxBJBEl7YCZP0OpZquPlh+2mdVaCjeecvhXzOw7fqTRvzI8unpHdYM2j0 Q6MGIG6tPssEc/n0OEL0KXNZ76/6wBZ0T7dx7uLMlfXqgJxq+8h6i2AvlH8K7gU9L8mGOf hzACPGDkhevbgVYgG1XE6n62XG6EYRQ= Received: by mail-wm1-f47.google.com with SMTP id p16so7433078wmq.5 for ; Mon, 13 Mar 2023 02:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1678700588; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=DxxClasutQ5PqW8TvU53BWsXOs7xcuC+RTlUJtJP2sQ=; b=h3TDpuYDAZfdPTrBvLxzsaXRKlJ9Q2jh2tNMraEiLGXymopAzOnui7kQZzxhmFXH8J QUQb19c/7fWEfIxTecp+uIIBJrB4l2pT6kLWe6Lcaz/zDH8THjKLVjJbb0HtACHBiMfZ sPAK1rVIqSfxNdNUlxieZptHZPSRh3jCXGTJG6+12nVcrQ1MA8olf1I7EQKV61Jo7m1N Mme6I5sKzEsCzXwBaISzU8LY/lW8feJ9hfbB39JCJdGmp102x/WISLrY9w13owNvQOuD TixAk0UX6bQnuIMDAOivDU2sfb/YGuYJrrDmJj+peefVIY6wb/UtTVcpuXxE849Hpfgn NcoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678700588; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DxxClasutQ5PqW8TvU53BWsXOs7xcuC+RTlUJtJP2sQ=; b=71ghLkeXX1/6rzE3xJfiytsfRtFEspO40d9jlhZ2uDcnXwA1RwLsF8kZPoiLVDjlja xkidku+juaygPBOrl0rhHAET8TlNsdedtinEd9CvezRPBaqR+UUWbA3vcgwgOD+KXNGM nLmRK41E/s+c/ZcEzolrjJhu6yHEE4xa7iUkWZHvg1UrpGIjVRVhDgjKv3LhyBEWLwvk 17umQhOLBmSC0ENHSf4g6o2Idx9+fcAfJ8jhzILeg0BwM+MRQAjld1UIyzPnTHjEbaVJ oL+y+CUc8g5PX1gyRlbGTZxHjWLsrr41z/XO5T2IZiH0Gt/wh5DWcqevtbJTddQDdXAT ZD0Q== X-Gm-Message-State: AO0yUKUU44FwG3W9F6bcP6O1u3LPuyD5u5okbARrXV/kkHWbTdVHEySr KR9A5xz4uFPHhCaUF6ND5dKEuA== X-Google-Smtp-Source: AK7set/gu2v5+Z4pvLuyJomxbp4JRixpfwOaaAR1zN7y2b+8QDashQHnd4D6nxFOJYocB2azbkFjxw== X-Received: by 2002:a05:600c:4ed4:b0:3ed:26c1:8e5a with SMTP id g20-20020a05600c4ed400b003ed26c18e5amr1294483wmq.10.1678700588496; Mon, 13 Mar 2023 02:43:08 -0700 (PDT) Received: from localhost (cst2-173-16.cust.vodafone.cz. [31.30.173.16]) by smtp.gmail.com with ESMTPSA id v7-20020a05600c444700b003e204fdb160sm9192391wmn.3.2023.03.13.02.43.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Mar 2023 02:43:08 -0700 (PDT) Date: Mon, 13 Mar 2023 10:43:06 +0100 From: Andrew Jones To: Alexandre Ghiti Cc: Catalin Marinas , Will Deacon , Paul Walmsley , Palmer Dabbelt , Albert Ou , Rob Herring , Frank Rowand , Mike Rapoport , Andrew Morton , Anup Patel , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v7 3/4] arm64: Make use of memblock_isolate_memory for the linear mapping Message-ID: <20230313094306.6kslmrdixuw75iqf@orel> References: <20230310094539.764357-1-alexghiti@rivosinc.com> <20230310094539.764357-4-alexghiti@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230310094539.764357-4-alexghiti@rivosinc.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 100DB40004 X-Rspam-User: X-Stat-Signature: 5subxy8p4iq4q4qyyqnujuaisk3okh9n X-HE-Tag: 1678700589-563473 X-HE-Meta: U2FsdGVkX19Fjy53sQJPvqHJWGh9bJyABxYE2/RGL4ZsDskibGhGIw1639l8jGhuwwy02nL7i5HTtesYPlAZnbCEjTt0aF8a4iuIVQsCCPMHwahcE3uaMbtO6Fi9cQc4kXOSpIKQBKuQJzJu0IonlL3yzPVy1nXd6uGPvNBjXSpds4WKLXCm6LczY4h++QGHLU+DpDp9tLMhpBu1J/02k1HBiy3poEpVbafdhZlhpPN+aO1U9Guhm2U1de9qogEudKUPZqIVhByVyh1KKgZjrh9AzBuZfDbD+cvGsx1XaAOrozO0V0+HsvPRHow8fvWccJFrgQSXng6g79h4RSgTAgMAryn7YLQ6AHHUkYMAdWVMaROW6HTXNnZqrvstmzns0IMVckc+r0NqaNVBuGg5fT05URvucsnUJf6fuBikeWQF3IuRGh8bvg5ViYs6uM9Vxqq/JUv/xTnHvq2Usws+iSe9djMtog0ir6O1vXTLBy8tuDE7YePqhdsf4IuOzcodO2Oyp1ue0b/DDqRKS2V/OIvUFOmdUrt+6wJD/lLSgMl6/svMWTOlAdL6qpcu2AMTkZQWYV99cFDrKyKrvAq8P9OpZblaQf8xbuxAq0jIlfd1jdfU3D8F83FtXtLhn02twAhv/lPXAjMhfhQDK3D2HRVlAkF6BvxRes95KMjQVNUOB9UGF/08a4TK5PwZMbS3Rk62hTF16PVFBm+YGgSkPgRK5syEkgP7q5+6rnj5x9sMAVCuezXwHBJavTVHgK4W+0hGQV3PLpqm17UW4G1sBlwBn1nRvFNcDlfknNioi17WMD7++Yib3OieltusPpPCAqnnBKiqFmJpvshGBF1ay11eujHK22TbMj+VnmJAJSg+Er/BReyuJuTpxdP0+Q0Zmq8jMZW5dcKmGJYFSjIZQcGNWQTcmLKMECOkP9wRiLi6i+0a5TToWIfVSuAWnAj50sgMGGxDywrYhYhaPPn bDgAS888 Dv2QQu1sKr8sbz73ZuxjEaqAS+dremaaVlvi6rIGYcTRls3SWVrNa3M8UoCazxAvgOy4Wxvocbsex7n90cEMxAiMjuMZySVGYqD5Kqp6dToP0f+7Gc/CzMWsD+YmHlaXkhwHbpKBGuYs2p+u9nh977ub6xgl2QAnvQ0LzmresXQ3o6vMSutq/5cAunf7xGQRjWSQWTSmzbfjT0neGGKlTC/Jz3SPGQJorYE11OB56QfDJlW6wlk/FoleFmh5cWiT+x3zaBkmNxkNiaudFbSkPeHzYzslWxAZaec9zTcroOUbvmvETb5v5FURZGmTCp5g4lNhYS2K2Y7CyCnZI61SsmZodeYCRq2MX+AL9b2ze0GJXATrXE48Wo0zdkSJ0TDFb/Z44awdXemJLjohyKLUVdsYXhthXH8VXNAYP8HGN1msTIcuo+tbob8UpLUEtYpEqQB+XwKIkKwYC3ZKSI3nowZ1dWhaKwJY1ZUJDIhD1ZV72q9MsekebF6or9ADoCOhwE46QbxGwIcQHgSyPIUcftgvYEJz/dElaLCR2nhE7Q7W1C2RPQcDB5YlAna0NpSci6CqhWWkccqwct0YVpSJhhVpD6Slr9wKYD1ek 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 Fri, Mar 10, 2023 at 10:45:38AM +0100, Alexandre Ghiti wrote: > In order to isolate the kernel text mapping, we used some sort of hack > to isolate the kernel text range which consisted in marking this region > as not mappable with memblock_mark_nomap. Simply use the newly introduced > memblock_isolate_memory function which does exactly the same but does not > uselessly mark the region as not mappable. > > Signed-off-by: Alexandre Ghiti > --- > arch/arm64/mm/mmu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index 6f9d8898a025..408dc852805c 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -552,7 +552,7 @@ static void __init map_mem(pgd_t *pgdp) > * So temporarily mark them as NOMAP to skip mappings in > * the following for-loop > */ The comment above doesn't apply anymore. > - memblock_mark_nomap(kernel_start, kernel_end - kernel_start); > + memblock_isolate_memory(kernel_start, kernel_end - kernel_start); > > #ifdef CONFIG_KEXEC_CORE > if (crash_mem_map) { > @@ -568,6 +568,7 @@ static void __init map_mem(pgd_t *pgdp) > for_each_mem_range(i, &start, &end) { > if (start >= end) > break; > + Mark nomap is also used for the crash kernel. Does the new API not work for it? Thanks, drew > /* > * The linear map must allow allocation tags reading/writing > * if MTE is present. Otherwise, it has the same attributes as > @@ -589,7 +590,6 @@ static void __init map_mem(pgd_t *pgdp) > */ > __map_memblock(pgdp, kernel_start, kernel_end, > PAGE_KERNEL, NO_CONT_MAPPINGS); > - memblock_clear_nomap(kernel_start, kernel_end - kernel_start); > > /* > * Use page-level mappings here so that we can shrink the region > -- > 2.37.2 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv