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 740B8C25B74 for ; Tue, 21 May 2024 21:21:52 +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=zWvIGNpoUgCh9JQ1pgjXxL6mMkwyMsFVxCNEsTVHr8o=; b=GXIL61VDTgUJRA kfmMAvs64z2CYhd8DRuyRMVwIXFYvRlH66MYLngkfQmrKIanSrkhVzD9mUN9aNghnSpfPnURjLtS3 ZlS4Ld1gf3v7/JJcN83OQUqraGhWWlsQCmvLxT392/54TBeiT+4QujyOKgDta0q48qz5Kz3Sv4gqn WW96B+7t8f7TObc7LxRkhlkYNpchYushmklLwKHrABhkwGlSeZgFBuwDvdhBUcSVDF1A1YfZVdgmO PagAlCnzjb3LTigek/ma5OF4b/Rp3hJPFPezQa/EBmsYer/Tyg11kL+ThYylW/m5ZhhYjCYNK5EUY e00sgZp1A+mAKk50ksyQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9WvU-000000019Ab-1gjk; Tue, 21 May 2024 21:21:40 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9WvS-000000019AA-1DPM for linux-arm-kernel@lists.infradead.org; Tue, 21 May 2024 21:21:39 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 782AE61792; Tue, 21 May 2024 21:21:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 253D1C2BD11; Tue, 21 May 2024 21:21:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716326497; bh=nQ1+kno34eRI2CH2p2WJJVVsGQQJyU67WUCjO0bZSl0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tFMxKqTkH0J63NBvzY/8ND0t6Po+mj0NUorz1VwnLfLo3KrLv+D/CeXXmrtSHGhqG 63ugiU3agCp8NaWTqR3GbtgIFmjbFXsP9T/THK3eaAdAnzOJqVlyac+6gyFKrIdot2 GLIFCojpHYKp81v2T0sI6VRX+G2ZCmFHY/ZN0/cXjjiJQ8gUtvmEx13WrO5R1rjBgt FAuaL+FIMbbbXv08yTAZ7+qa092XeZnzHaCN5Fd1E5p26OVLnntA/5eIV9GD2CjtGO c4A4ZEG1uPgMBPnixurUE1MeH2mTdSEvl/9KHQc8qN4leiTnvDYBNC6ROR62KEDxEG O1rTFMRBZ995w== 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 1s9WvO-00Eo3U-F5; Tue, 21 May 2024 22:21:34 +0100 Date: Tue, 21 May 2024 22:21:33 +0100 Message-ID: <86r0dun9nm.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, will@kernel.org, qperret@google.com, seanjc@google.com, alexandru.elisei@arm.com, catalin.marinas@arm.com, philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, mark.rutland@arm.com, broonie@kernel.org, joey.gouly@arm.com, rananta@google.com, yuzenghui@huawei.com Subject: Re: [PATCH v2 4/7] KVM: arm64: Store the maximum sve vector length at hyp In-Reply-To: <20240521163720.3812851-5-tabba@google.com> References: <20240521163720.3812851-1-tabba@google.com> <20240521163720.3812851-5-tabba@google.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.2 (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: tabba@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, will@kernel.org, qperret@google.com, seanjc@google.com, alexandru.elisei@arm.com, catalin.marinas@arm.com, philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, mark.rutland@arm.com, broonie@kernel.org, joey.gouly@arm.com, rananta@google.com, yuzenghui@huawei.com 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-20240521_142138_446893_2DD7F24E X-CRM114-Status: GOOD ( 25.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 Tue, 21 May 2024 17:37:17 +0100, Fuad Tabba wrote: > > In subsequent patches, hyp needs to know the maximum sve vector > length for the host, without needing the trust the host for that. > This is used when allocating memory for the host sve state in the > following patch, as well as for allocating and restricting guest > sve state in a future patch series. > > Signed-off-by: Fuad Tabba > --- > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/include/asm/kvm_hyp.h | 1 + > arch/arm64/kvm/arm.c | 1 + > arch/arm64/kvm/hyp/nvhe/pkvm.c | 2 ++ > arch/arm64/kvm/reset.c | 2 ++ > 5 files changed, 7 insertions(+) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index 8170c04fde91..0a5fceb20f3a 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -76,6 +76,7 @@ static inline enum kvm_mode kvm_get_mode(void) { return KVM_MODE_NONE; }; > DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use); > > extern unsigned int __ro_after_init kvm_sve_max_vl; > +extern unsigned int __ro_after_init kvm_host_sve_max_vl; > int __init kvm_arm_init_sve(void); > > u32 __attribute_const__ kvm_target_cpu(void); > diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h > index 2ab23589339a..d313adf53bef 100644 > --- a/arch/arm64/include/asm/kvm_hyp.h > +++ b/arch/arm64/include/asm/kvm_hyp.h > @@ -143,5 +143,6 @@ extern u64 kvm_nvhe_sym(id_aa64smfr0_el1_sys_val); > > extern unsigned long kvm_nvhe_sym(__icache_flags); > extern unsigned int kvm_nvhe_sym(kvm_arm_vmid_bits); > +extern unsigned int kvm_nvhe_sym(kvm_host_sve_max_vl); > > #endif /* __ARM64_KVM_HYP_H__ */ > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 9996a989b52e..9e565ea3d645 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -2378,6 +2378,7 @@ static void kvm_hyp_init_symbols(void) > kvm_nvhe_sym(id_aa64smfr0_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64SMFR0_EL1); > kvm_nvhe_sym(__icache_flags) = __icache_flags; > kvm_nvhe_sym(kvm_arm_vmid_bits) = kvm_arm_vmid_bits; > + kvm_nvhe_sym(kvm_host_sve_max_vl) = kvm_host_sve_max_vl; > } > > static int __init kvm_hyp_init_protection(u32 hyp_va_bits) > diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c > index 16aa4875ddb8..25e9a94f6d76 100644 > --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c > +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c > @@ -18,6 +18,8 @@ unsigned long __icache_flags; > /* Used by kvm_get_vttbr(). */ > unsigned int kvm_arm_vmid_bits; > > +unsigned int kvm_host_sve_max_vl; > + > /* > * Set trap register values based on features in ID_AA64PFR0. > */ > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index 1b7b58cb121f..e818727900ec 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -46,11 +46,13 @@ static u32 __ro_after_init kvm_ipa_limit; > PSR_AA32_I_BIT | PSR_AA32_F_BIT) > > unsigned int __ro_after_init kvm_sve_max_vl; > +unsigned int __ro_after_init kvm_host_sve_max_vl; > > int __init kvm_arm_init_sve(void) > { > if (system_supports_sve()) { > kvm_sve_max_vl = sve_max_virtualisable_vl(); > + kvm_host_sve_max_vl = sve_max_vl(); Why the intermediate storage? Setting kvm_nvhe_sym(kvm_host_sve_max_vl) to sve_max_vl() should be enough. But it doesn't mean that all the CPUs support the same max VL, and I wonder whether we end-up with the wrong in-memory layout in this case... Thanks, 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