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 41080C433FE for ; Fri, 18 Nov 2022 11:54:51 +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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=p2Bu4RUBtk5t4aJiW+y4VtsYdWk12pLPs4lfcz8IpYU=; b=x9Jn7ZNRfYIEKL 8E2Mk1dSsuLSR3Q9EfQooN0GPml8wN82nXhSnukQ9PQe4STtMi1f+AcQBKAxTUhcdY5j91emvQErF gdONhKRWnCbFy869dCqd1PsZlXnT4sQ8BS/ALc5ZTWt0UlJX7YzwTZrMmvZSEzuE+kqB+2/DYqlCb g2GkOGzyA5lAdYvuODzPtUgRW6gXTgDxIfLNDyxgzkeguNCJt2Hb87SxelIr71GwWiYLLycY0QkMi nIPqsKu45u12cOrzaId0+hgDxrOea63LHabPNpbf5H9OTUSKwtX0M/ocNFG/lywbosVcQeFsrFNQu F2cCe4R+KC9tTKpNpkwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovzwI-003mGv-Rg; Fri, 18 Nov 2022 11:53:46 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovzwG-003mGS-9T for linux-arm-kernel@lists.infradead.org; Fri, 18 Nov 2022 11:53:46 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4D61F23A; Fri, 18 Nov 2022 03:53:48 -0800 (PST) Received: from [192.168.0.110] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ED1553F587; Fri, 18 Nov 2022 03:53:38 -0800 (PST) Message-ID: <36e8f3d0-6d10-b3ea-04df-e1de4d2ec7c6@arm.com> Date: Fri, 18 Nov 2022 17:23:35 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [RFC PATCH 0/7] arm64: Enable LPA2 support for 16k pages Content-Language: en-US To: Ard Biesheuvel , Catalin Marinas Cc: linux-arm-kernel@lists.infradead.org, Marc Zyngier , Will Deacon , Mark Rutland , Kees Cook , Mark Brown , Richard Henderson References: <20221117132423.1252942-1-ardb@kernel.org> From: Anshuman Khandual In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221118_035344_459098_730F0BBF X-CRM114-Status: GOOD ( 28.39 ) 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 11/18/22 16:20, Ard Biesheuvel wrote: > On Fri, 18 Nov 2022 at 11:38, Catalin Marinas wrote: >> >> Hi Ard, >> >> On Thu, Nov 17, 2022 at 02:24:16PM +0100, Ard Biesheuvel wrote: >>> Enable support for LPA2 when running with 16k pages. Unlike with 4k >>> pages, this does not require adding support for 5 level paging, but >>> beyond that, there is no fundamental difference between LPA2 support on >>> 4k or 16k pages. >> >> We have some patches already from Anshuman, targeting both 4K and 16K >> pages: >> >> https://lore.kernel.org/r/1632998116-11552-1-git-send-email-anshuman.khandual@arm.com >> > > Ah right - I was aware that Anshuman had been looking into this as > well, but I did not realise working code had been sent to the list. > > That series doesn't cover 5 level paging yet, right? The posted series last year was to enable 52 bit PA for all VA configs on 4K and 16K page sizes. There was a fix (and other changes) to idmap which enabled two additional idmap levels, to support much spaced VA-PA configs for FEAT_LPA2, but now those idmap changes need to be reworked after your recent boot code changes. But it never enabled 52 bit VA (although I had some local changes) which would have required proper 5 level paging. > >> I don't think they've been rebased on top of 6.1-rcX though. Could you >> please liaise with Anshuman and agree on a way forward? I'd rather only >> review a single series if they do the same thing. I have a preference >> for a more complete solution (4K and 16K) rather than just 16K pages. I >> think we can even ignore some corner cases like 39-bit VA (if anyone is >> asking, we could do it later but it doesn't seem realistic). >> > > If we can agree that we don't need more than 48 bits for the ID map > (at least for the time being), this all fits quite nicely on top of > the boot code refactor that i sent out last week, where the code in > head.S is only responsible for creating the [initial] ID map, and > everything else is done from C code. I have some changes to 'init_idmap_pg_dir' creation in the assembly code i.e create_idmap which gets [4K|52PA|48VA] to boot with kernel loaded beyond 48 bits PA. The problem is, it gets stuck at "smp: Bringing up secondary CPUs .." as the runtime 'idmap_pg_dir' created with C code create_idmap() does not handle (does not create required additional pgtable levels) when VA=48. Something else I discovered is that current 'idmap_pg_dir' does not work with an existing config [64K|52PA|48PA] when vmlinux is loaded beyond 48 bits PA. After fixing this existing problem, my plan was to enable it for FEAT_LPA2 configs on 4K/16K. > > I'll have a look today at how much additional work is needed on top of > this series to accommodate 4k 52-bit VA and PA support, but beyond > adding p4d handling in some places, I think it should be fairly > limited. > >> And a question for Anshuman: do you plan to refresh your series? >> > > Yeah let's align on a way forward here. Apologies for stepping on > this, I wasn't aware how much actual code you had already written. No worries. Let sync up on Monday, or any other time suitable for you. I can walk you through all that I have, all that planed etc, then we could figure out how to proceed further. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel