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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 981FAC4332F for ; Wed, 30 Nov 2022 14:51:43 +0000 (UTC) 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=gxB4oe2ibZVjKcHFENEAO9PTIkif2GVBtJ0Q+4kEPA4=; b=YXOs7riwgMKG47 DPxrP0a6Zez4RMjrb+RxFUHeqGm1qIZ1bDTahbUh2mUsr4k0SEMJnsng85D7zOu7uO096f6dSGGZN SwnPPkrFV15/5Twj9FpflYzOV7O13gSDORDykSww7+qQOi4Ne78xqJqI16lJEZHJacDqs1ofy2InK gwmTKeYV7Ykpfcf0j6GQiI5UStv5D7MbX3/M7BqWx0pxh/v0AZMNrdXaHpXuSzAMHhKv79YSdqK7k 9eFU2EplAz8F+iNWWzvsQ5VPgGxlsChYh+kDtS9yxAwP+fzH2KCXPtMnfqvva5eARIXs3wwUKO6K0 Wz+xOd8hBQY/uu46uwCg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0OPy-00H4xW-3D; Wed, 30 Nov 2022 14:50:34 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0OPu-00H4rA-Jz for linux-arm-kernel@lists.infradead.org; Wed, 30 Nov 2022 14:50:32 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 04EDDB81B91; Wed, 30 Nov 2022 14:50:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F06FC433D7; Wed, 30 Nov 2022 14:50:26 +0000 (UTC) Date: Wed, 30 Nov 2022 14:50:23 +0000 From: Catalin Marinas To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , Mark Rutland , Anshuman Khandual , Joey Gouly Subject: Re: [PATCH 2/3] arm64: mm: Handle LVA support as a CPU feature Message-ID: References: <20221115143824.2798908-1-ardb@kernel.org> <20221115143824.2798908-3-ardb@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221115143824.2798908-3-ardb@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221130_065030_821109_71A5D795 X-CRM114-Status: GOOD ( 21.37 ) 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, Nov 15, 2022 at 03:38:23PM +0100, Ard Biesheuvel wrote: > Currently, we detect CPU support for 52-bit virtual addressing (LVA) > extremely early, before creating the kernel page tables or enabling the > MMU. We cannot override the feature this early, and so large virtual > addressing is always enabled on CPUs that implement support for it if > the software support for it was enabled at build time. It also means we > rely on non-trivial code in asm to deal with this feature. > > Given that both the ID map and the TTBR1 mapping of the kernel image are > guaranteed to be 48-bit addressable, it is not actually necessary to > enable support this early, and instead, we can model it as a CPU > feature. That way, we can rely on code patching to get the correct > TCR.T1SZ values programmed on secondary boot and suspend from resume. > > On the primary boot path, we simply enable the MMU with 48-bit virtual > addressing initially, and update TCR.T1SZ from C code if LVA is > supported, right before creating the kernel mapping. Given that TTBR1 > still points to reserved_pg_dir at this point, updating TCR.T1SZ should > be safe without the need for explicit TLB maintenance. I'm not sure we can skip the TLBI here. There's some weird rule in the ARM ARM that if you change any of fields that may be cached in the TLB, maintenance is needed even if the MMU is off. From the latest version (I.a, I didn't dig into H.a), R_VNRFW: When a System register field is modified and that field is permitted to be cached in a TLB, software is required to invalidate all TLB entries that might be affected by the field, at any address translation stage in the translation regime even if the translation stage is disabled, using the appropriate VMID and ASID, after any required System register synchronization. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel