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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 4555BC4338F for ; Tue, 3 Aug 2021 13:33:33 +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 1013260F45 for ; Tue, 3 Aug 2021 13:33:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1013260F45 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=K/8mshD29V2yqzk0qdlRWyekz6NtHL6jEm8cSnKtDag=; b=C+tGaRIuk5PVPU +zKweJkzSFcgDLXVeqqwWJHbiLV95+Iv3fughiKfPS1vDuxIRvR8yuz5rsnciIkzBbDinkm1OVysv knZlSAZnckfashmGmk2fZeJkj+ZPl9jI8HB5BYRSOGpJMFvq7URTBAo8lYYZgi2PJxM0dM9t8jiye U5xm2ftb3TItmSgwDakBlEGzpI6xZLCpy4YwSmvjJ1oPzzdMSjIGgy4GUY/NdrggNMSuq1oSXGOrD mBWpX7V8WHXwxawWYVQtPYMrmLzX7UYvZqQKNh2NHmxpTTRng/4geUFpOrznywbZd52B+v7UPz+u+ XiEMsDX45jqiQ0EupKoQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAuW0-0032Jl-RA; Tue, 03 Aug 2021 13:31:29 +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 1mAuDG-002tmi-TN for linux-arm-kernel@lists.infradead.org; Tue, 03 Aug 2021 13:12:08 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6330160EFD; Tue, 3 Aug 2021 13:12:05 +0000 (UTC) Date: Tue, 3 Aug 2021 14:12:02 +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: <20210803131201.GB5786@arm.com> References: <1627879359-30303-1-git-send-email-anshuman.khandual@arm.com> <20210803103440.GA5786@arm.com> <7bad50a2-76f1-7946-3a15-35e46fb289c0@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7bad50a2-76f1-7946-3a15-35e46fb289c0@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_061207_092153_8B6F076E X-CRM114-Status: GOOD ( 33.74 ) 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 Tue, Aug 03, 2021 at 04:57:04PM +0530, Anshuman Khandual wrote: > On 8/3/21 4:04 PM, Catalin Marinas wrote: > > On Mon, Aug 02, 2021 at 10:12:39AM +0530, Anshuman Khandual wrote: > >> +/* > >> + * 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) I don't think you need the PA_BITS_48 check in here. It's either this one or PA_BITS_52 in the future. Anyway, I think so far our assumption is that the kernel will always be placed in the first 48-bit, so we don't need extra check. > >> + 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. > > Right but its bit tricky here. > > __idmap_text_end could be any where between VA_BITS (36) and PA_BITS (48) > which would require (one or two) additional page table levels. But in this > solution it creates two additional page table levels for idmap which would > completely map upto PA_BITS, regardless of __idmap_text_end's position. So > in case __idmap_text_end is between VA_BITS (36) and VA_BITS(47), a single > additional page table level is required where as we have created two ! So > to avoid such a situation, adjust idmap_t0sz accordingly. Otherwise there > will be a MMU mis-configuration. I get it now. You need 4 levels with 16K pages for idmap as 3 levels (one extra in head.S) are not sufficient. The normal page table uses 2 levels with 36-bit VA. Here you chose to go with 4 levels always as the simplest option. Do we need to adjust idmap_ptrs_per_pgd? I think even without your patch, its value is wrong as it doesn't seem to be adjusted for the extra level. I can't figure out whether it matter but I think we should remove this variable altogether and just set the x4 register to what we need in head.S > This patch is indented for stable back port and hence tries to be as simple > and minimal as possible. So it creates two additional page table levels > mapping upto PA_BITS without just considering __idmap_text_end's position. > Reducing __idmap_t0sz upto PA_BITS should not be a problem irrespective of > ID_AA64MMFR0_EL1.PARANGE value. As __idmap_text_end would never be on a PA > which is not supported. Hence out of range PA would never be on the bus for > translation. I'd rather have a clean solution (might as well be this one) than worrying about a stable back-port. It's highly unlikely that we'll trip over this problem in practice: first you'd need RAM above 47-bit and second you'd have to enable EXPERT and 36-bit VA. It looks like idmap_t0sz is used by the kvm_mmu_init() code to calculate hyp_va_bits. Does it mean that idmap_t0sz should always match PA_SIZE? Or maybe we should just decouple the two. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel