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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 398CBC4338F for ; Tue, 3 Aug 2021 10:35:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1C03060F01 for ; Tue, 3 Aug 2021 10:35:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235516AbhHCKfL (ORCPT ); Tue, 3 Aug 2021 06:35:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:36862 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235388AbhHCKez (ORCPT ); Tue, 3 Aug 2021 06:34:55 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B87F060F01; Tue, 3 Aug 2021 10:34:43 +0000 (UTC) Date: Tue, 3 Aug 2021 11:34:41 +0100 From: Catalin Marinas To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , James Morse , Marc Zyngier , Mark Rutland , linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64/mm: Fix idmap on [16K|36VA|48PA] Message-ID: <20210803103440.GA5786@arm.com> References: <1627879359-30303-1-git-send-email-anshuman.khandual@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1627879359-30303-1-git-send-email-anshuman.khandual@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 02, 2021 at 10:12:39AM +0530, Anshuman Khandual wrote: > When creating the idmap, the kernel may add one extra level to idmap memory > outside the VA range. But for [16K|36VA|48PA], we need two levels to reach > 48 bits. If the bootloader places the kernel in memory above (1 << 46), the Did you mean (1 << 36)? > kernel will fail to enable the MMU. Although we are not aware of a platform > where this happens, it is worth to accommodate such scenarios and prevent a > possible kernel crash. > > Lets fix the problem on the above configuration by creating two additional > idmap page table levels when 'idmap_text_end' is outside the VA range. This > reduces 'idmap_t0sz' to cover the entire PA range which would prevent table > misconfiguration (fault) when a given 'idmap_t0sz' value requires a single > additional page table level where as two have been built. [...] > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > index c5c994a..da33bbc 100644 > --- a/arch/arm64/kernel/head.S > +++ b/arch/arm64/kernel/head.S > @@ -329,7 +329,9 @@ SYM_FUNC_START_LOCAL(__create_page_tables) > > #if (VA_BITS < 48) > #define EXTRA_SHIFT (PGDIR_SHIFT + PAGE_SHIFT - 3) > +#define EXTRA_SHIFT_1 (EXTRA_SHIFT + PAGE_SHIFT - 3) > #define EXTRA_PTRS (1 << (PHYS_MASK_SHIFT - EXTRA_SHIFT)) > +#define EXTRA_PTRS_1 (1 << (PHYS_MASK_SHIFT - EXTRA_SHIFT_1)) > > /* > * If VA_BITS < 48, we have to configure an additional table level. > @@ -342,8 +344,30 @@ SYM_FUNC_START_LOCAL(__create_page_tables) > #error "Mismatch between VA_BITS and page size/number of translation levels" > #endif > > +/* > + * In this particular CONFIG_ARM64_16K_PAGES config, there might be a > + * scenario where 'idmap_text_end' ends up high enough in the PA range > + * requiring two additional idmap page table levels. Reduce idmap_t0sz > + * to cover the entire PA range. This prevents table misconfiguration > + * when a given idmap_t0sz value just requires single additional level > + * where as two levels have been built. > + */ > +#if defined(CONFIG_ARM64_VA_BITS_36) && defined(CONFIG_ARM64_PA_BITS_48) > + mov x4, EXTRA_PTRS_1 > + create_table_entry x0, x3, EXTRA_SHIFT_1, x4, x5, x6 > + > + mov x4, PTRS_PER_PTE > + create_table_entry x0, x3, EXTRA_SHIFT, x4, x5, x6 > + > + mov x5, #64 - PHYS_MASK_SHIFT > + adr_l x6, idmap_t0sz > + str x5, [x6] > + dmb sy > + dc ivac, x6 > +#else > mov x4, EXTRA_PTRS > create_table_entry x0, x3, EXTRA_SHIFT, x4, x5, x6 > +#endif > #else > /* > * If VA_BITS == 48, we don't have to configure an additional There's a prior idmap_t0sz setting based on __idmap_text_end. Isn't that sufficient? We don't care about covering the whole PA space, just the __idmap_text_end. -- Catalin 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=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 1D8CBC4338F for ; Tue, 3 Aug 2021 10:38:15 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DE591600D4 for ; Tue, 3 Aug 2021 10:38:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DE591600D4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yi+R3/KYRQg2Za4BhTZ+Rddc2RUoXzJAY5IXIQP0asA=; b=H6FTS39CtFn05L mz9W0Z+3w680NMNw1sNKU449ZD7KuyspoR6eWeGuKvS2iPLk6Tlk6GeDcK3HnXF9l3uGpGLmGTTmH 7xosf+Pbo0CuqYD9A7m2Vs7jlNuhMuMuI05L9nUIsj2GWJmTV9vTIypAp4CSec935UduV1jRWd32w 0BYmMvjDM/uWPzKOovZcnt0yzY8y3O/Pm2ZMp4uwzSf3+v4PbTdK0XQ43DxrTBnw2j/W5UH31Ckf7 ibWe83hLuRtrM2OozBtTGdec+Cn36MTauYPDhBi7g7FuOAsbCOAmaW/zbam3pVQ3AIdNGlol/BV+y H2bDQyTy0m6u+CGwW+6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mArmF-0024hU-9w; Tue, 03 Aug 2021 10:36:03 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mArkz-0024AF-6r for linux-arm-kernel@lists.infradead.org; Tue, 03 Aug 2021 10:34:47 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id B87F060F01; Tue, 3 Aug 2021 10:34:43 +0000 (UTC) Date: Tue, 3 Aug 2021 11:34:41 +0100 From: Catalin Marinas To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , James Morse , Marc Zyngier , Mark Rutland , linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64/mm: Fix idmap on [16K|36VA|48PA] Message-ID: <20210803103440.GA5786@arm.com> References: <1627879359-30303-1-git-send-email-anshuman.khandual@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1627879359-30303-1-git-send-email-anshuman.khandual@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210803_033445_305293_9DD66DBF X-CRM114-Status: GOOD ( 21.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Aug 02, 2021 at 10:12:39AM +0530, Anshuman Khandual wrote: > When creating the idmap, the kernel may add one extra level to idmap memory > outside the VA range. But for [16K|36VA|48PA], we need two levels to reach > 48 bits. If the bootloader places the kernel in memory above (1 << 46), the Did you mean (1 << 36)? > kernel will fail to enable the MMU. Although we are not aware of a platform > where this happens, it is worth to accommodate such scenarios and prevent a > possible kernel crash. > > Lets fix the problem on the above configuration by creating two additional > idmap page table levels when 'idmap_text_end' is outside the VA range. This > reduces 'idmap_t0sz' to cover the entire PA range which would prevent table > misconfiguration (fault) when a given 'idmap_t0sz' value requires a single > additional page table level where as two have been built. [...] > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > index c5c994a..da33bbc 100644 > --- a/arch/arm64/kernel/head.S > +++ b/arch/arm64/kernel/head.S > @@ -329,7 +329,9 @@ SYM_FUNC_START_LOCAL(__create_page_tables) > > #if (VA_BITS < 48) > #define EXTRA_SHIFT (PGDIR_SHIFT + PAGE_SHIFT - 3) > +#define EXTRA_SHIFT_1 (EXTRA_SHIFT + PAGE_SHIFT - 3) > #define EXTRA_PTRS (1 << (PHYS_MASK_SHIFT - EXTRA_SHIFT)) > +#define EXTRA_PTRS_1 (1 << (PHYS_MASK_SHIFT - EXTRA_SHIFT_1)) > > /* > * If VA_BITS < 48, we have to configure an additional table level. > @@ -342,8 +344,30 @@ SYM_FUNC_START_LOCAL(__create_page_tables) > #error "Mismatch between VA_BITS and page size/number of translation levels" > #endif > > +/* > + * In this particular CONFIG_ARM64_16K_PAGES config, there might be a > + * scenario where 'idmap_text_end' ends up high enough in the PA range > + * requiring two additional idmap page table levels. Reduce idmap_t0sz > + * to cover the entire PA range. This prevents table misconfiguration > + * when a given idmap_t0sz value just requires single additional level > + * where as two levels have been built. > + */ > +#if defined(CONFIG_ARM64_VA_BITS_36) && defined(CONFIG_ARM64_PA_BITS_48) > + mov x4, EXTRA_PTRS_1 > + create_table_entry x0, x3, EXTRA_SHIFT_1, x4, x5, x6 > + > + mov x4, PTRS_PER_PTE > + create_table_entry x0, x3, EXTRA_SHIFT, x4, x5, x6 > + > + mov x5, #64 - PHYS_MASK_SHIFT > + adr_l x6, idmap_t0sz > + str x5, [x6] > + dmb sy > + dc ivac, x6 > +#else > mov x4, EXTRA_PTRS > create_table_entry x0, x3, EXTRA_SHIFT, x4, x5, x6 > +#endif > #else > /* > * If VA_BITS == 48, we don't have to configure an additional There's a prior idmap_t0sz setting based on __idmap_text_end. Isn't that sufficient? We don't care about covering the whole PA space, just the __idmap_text_end. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel