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 D07FFC61D97 for ; Wed, 22 Nov 2023 15:21:46 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7Hp5ifpocXn4KDquSRkDK36cA3Uj2Pe/Vb4XKkTkggA=; b=xg02wruIXuV7zT eLeLHm1FCyz6xs/rx/ER4J8KeVs5DZ2cErUJwyisoCw2uPaMqjkjI7JCt6DaS9WzJ8KoZb15GW0mI 8ItBS2xsjVZdmYeeE+/lvbyOT5ZSG5WVgALr6N4CoC8gR8Y26U50HjoyY0mJ055U/EkYstOUYe2BQ 2vzWngej/kXAZbdFKvIF4k0P1XDR1maRI4U3FQ9t4sdXKObAmJ/T1x8hNryY+I0WcUHS0iPymIqgg +dOdvf1jXLv87KM/yl+Ul3zNQwj7h1MGr43tzhwzFfS+TuCtksWvLJMoFby5dO14/DTFK2xO0YLG1 X2tjk5Fb8OagU4xo+6kA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r5p2P-002EN3-0S; Wed, 22 Nov 2023 15:21:13 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r5p2L-002EMQ-23 for linux-arm-kernel@lists.infradead.org; Wed, 22 Nov 2023 15:21:11 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 4143CB81002; Wed, 22 Nov 2023 15:21:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D3B3C433C7; Wed, 22 Nov 2023 15:21:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700666467; bh=Ol98Vzn3PAkLXaEpLN54HRw08Lud9vsVssocBidrtg8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SUeybMPRZ23fhTB1nWR0Y9GjvtLF4/9XvrGcrgMQTzAlUTGeV89h3v3Gyb6ijGqH5 kDUw4SI9LEYNe3bVc5mvnQd+LjdwMLYahzCPZyQB2VdbR8pPGZZ7jesK12uxN9FqMQ qLTb6ynTw7Ux/6K1uobS6ADMEfPapGMyoeLtA+OyUxc3WmRu9odvwrx0oBjFJ2pT0s hjkJr+k2cpk7fr4NMjvJVdrRsNUXNKBW7attYqaccJZ4QQ/RslW2SOfvXYrOoxymfP oHcH6PdccoodCvGSCBuG3Q1XoGmFniGgsyAbbViuWUzABUqMLzXsS3Fd5rjrwKaiLE ME/pHssfTVLBQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1r5p2G-00FT9A-LB; Wed, 22 Nov 2023 15:21:04 +0000 Date: Wed, 22 Nov 2023 15:21:04 +0000 Message-ID: <86fs0xzue7.wl-maz@kernel.org> From: Marc Zyngier To: Ryan Roberts Cc: Oliver Upton , Catalin Marinas , Will Deacon , Suzuki K Poulose , James Morse , Zenghui Yu , Ard Biesheuvel , Anshuman Khandual , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v5 07/12] KVM: arm64: Use LPA2 page-tables for stage2 and hyp stage1 In-Reply-To: References: <20231116142931.1675485-1-ryan.roberts@arm.com> <20231116142931.1675485-8-ryan.roberts@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ryan.roberts@arm.com, oliver.upton@linux.dev, catalin.marinas@arm.com, will@kernel.org, suzuki.poulose@arm.com, james.morse@arm.com, yuzenghui@huawei.com, ardb@kernel.org, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231122_072109_995517_FDC89755 X-CRM114-Status: GOOD ( 39.00 ) 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 Wed, 22 Nov 2023 13:41:33 +0000, Ryan Roberts wrote: > > On 21/11/2023 20:34, Oliver Upton wrote: > > On Thu, Nov 16, 2023 at 02:29:26PM +0000, Ryan Roberts wrote: > >> Implement a simple policy whereby if the HW supports FEAT_LPA2 for the > >> page size we are using, always use LPA2-style page-tables for stage 2 > >> and hyp stage 1 (assuming an nvhe hyp), regardless of the VMM-requested > >> IPA size or HW-implemented PA size. When in use we can now support up to > >> 52-bit IPA and PA sizes. > >> > >> We use the previously created cpu feature to track whether LPA2 is > >> supported for deciding whether to use the LPA2 or classic pte format. > >> > >> Note that FEAT_LPA2 brings support for bigger block mappings (512GB with > >> 4KB, 64GB with 16KB). We explicitly don't enable these in the library > >> because stage2_apply_range() works on batch sizes of the largest used > >> block mapping, and increasing the size of the batch would lead to soft > >> lockups. See commit 5994bc9e05c2 ("KVM: arm64: Limit > >> stage2_apply_range() batch size to largest block"). > >> > >> With the addition of LPA2 support in the hypervisor, the PA size > >> supported by the HW must be capped with a runtime decision, rather than > >> simply using a compile-time decision based on PA_BITS. For example, on a > >> system that advertises 52 bit PA but does not support FEAT_LPA2, A 4KB > >> or 16KB kernel compiled with LPA2 support must still limit the PA size > >> to 48 bits. > >> > >> Therefore, move the insertion of the PS field into TCR_EL2 out of > >> __kvm_hyp_init assembly code and instead do it in cpu_prepare_hyp_mode() > >> where the rest of TCR_EL2 is prepared. This allows us to figure out PS > >> with kvm_get_parange(), which has the appropriate logic to ensure the > >> above requirement. (and the PS field of VTCR_EL2 is already populated > >> this way). > >> > >> Signed-off-by: Ryan Roberts > >> --- > >> arch/arm64/include/asm/kvm_mmu.h | 2 +- > >> arch/arm64/include/asm/kvm_pgtable.h | 47 +++++++++++++++++++++------- > >> arch/arm64/kvm/arm.c | 5 +++ > >> arch/arm64/kvm/hyp/nvhe/hyp-init.S | 4 --- > >> arch/arm64/kvm/hyp/pgtable.c | 15 +++++++-- > >> 5 files changed, 54 insertions(+), 19 deletions(-) > >> > >> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h > >> index 31e8d7faed65..f4e4fcb35afc 100644 > >> --- a/arch/arm64/include/asm/kvm_mmu.h > >> +++ b/arch/arm64/include/asm/kvm_mmu.h > >> @@ -340,7 +340,7 @@ static inline struct kvm *kvm_s2_mmu_to_kvm(struct kvm_s2_mmu *mmu) > >> return container_of(mmu->arch, struct kvm, arch); > >> } > >> > >> -#define kvm_lpa2_is_enabled() false > >> +#define kvm_lpa2_is_enabled() system_supports_lpa2() > > > > Can we use this predicate consistently throughout the KVM code? Looks > > like the rest of this diff is using system_supports_lpa2() directly. > > My thinking was that system_supports_lpa2() is an input to KVM's policy to > decide if it is going to use LPA2 (currently that policy is very simple - if the > system supports it, then KVM uses it - but it doesn't have to be that way), and > kvm_lpa2_is_enabled() is how KVM exports its policy decision, so one is an input > and the other is an output. > > It's a lightly held opinion though - I'll make the change if you insist? :) I personally don't find this dichotomy very useful. It could make sense if we used the page table walker for S1 outside of KVM, but that's not the case at the moment. If there is no plan for such a use case, I'd rather see a single predicate, making the code a bit more readable. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel